NCSC-TG-024 Vol. 2/4: A Guide to Procurement of Trusted Systems: Language for RFP Specifications and Statements of Work - An Aid to Procurement Initiators, 30 June 1993. (Purple Book)
c6f893c8c0a8fce8734ac5e51e95321e1c532e3f4119b209a94aef4d8352ecd2<HR><H2>Table of Contents</H2>
<UL>
<A HREF="procure2.html#HDR 2 6"><B><B>FOREWORD</B></B></A>
<BR>
<A HREF="procure2.html#HDR 2 7"><B><B>ACKNOWLEDGMENTS</B></B></A>
<BR>
<A HREF="procure2.html#HDR1 2 8"><B>1 GENERAL INFORMATION</B></A>
<UL>
<A HREF="procure2.html#HDR1.1 3 8">1.1 INTRODUCTION </A>
<BR>
<A HREF="procure2.html#HDR1.2 3 8">1.2 PURPOSE</A>
<UL>
<A HREF="procure2.html#HDR1.2.1 4 8">1.2.1 FACILITATING THE CONTRACTING
PROCESS</A>
<BR>
<A HREF="procure2.html#HDR1.2.2 4 9">1.2.2 FACILITATING FAIRNESS IN
COMPETITIVE ACQUISITION</A>
<BR>
<A HREF="procure2.html#HDR1.2.3 4 9">1.2.3 MINIMIZING PROCUREMENT COST AND
RISK</A>
<BR>
<A HREF="procure2.html#HDR1.2.4 4 10">1.2.4 ENSURING THE SOLICITATION IS
COMPLETE BEFORE ISSUANCE</A>
</UL>
<A HREF="procure2.html#HDR1.3 3 10">1.3 SCOPE</A>
<BR>
<A HREF="procure2.html#HDR1.4 3 11">1.4 BACKGROUND</A>
</UL>
<A HREF="procure2.html#HDR2 2 11"><B>2 PROCUREMENT PROCESS</B></A>
<BR>
<A HREF="procure2.html#HDR3 2 13"><B>3 REQUEST FOR PROPOSAL</B></A>
<UL>
<A HREF="procure2.html#HDR3.1 3 13">3.1 SECTION C - DESCRIPTIONS/
SPECIFICATIONS</A>
<BR>
<A HREF="procure2.html#HDR3.2 3 14">3.2 SECTION C - STATEMENTS OF WORK
(SOW)</A>
<BR>
<A HREF="procure2.html#HDR3.3 3 14">3.3 SECTION F - DELIVERIES AND
PERFORMANCE</A>
<BR>
<A HREF="procure2.html#HDR3.4 3 14">3.4 SECTION H - SPECIAL CONTRACT
REQUIREMENTS</A>
<BR>
<A HREF="procure2.html#HDR3.5 3 14">3.5 SECTION J - LIST OF DOCUMENTS,
EXHIBITS AND OTHER ATTACHMENT</A>
<BR>
<A HREF="procure2.html#HDR3.6 3 15">3.6 SECTION L - INSTRUCTIONS,
CONDITIONS, AND NOTICES TO OFFERORS</A>
<BR>
<A HREF="procure2.html#HDR3.7 3 15">3.7 SECTION M - EVALUATION FACTORS FOR
AWARD</A>
</UL>
<A HREF="procure2.html#HDR4 2 15"><B>4 OTHER CONSIDERATIONS</B></A>
<UL>
<A HREF="procure2.html#HDR4.1 3 15">4.1 NONMANDATORY REQUIREMENTS AND
OPTIONS</A>
<BR>
<A HREF="procure2.html#HDR4.2 3 16">4.2 EVIDENCE AVAILABILITY</A>
<BR>
<A HREF="procure2.html#HDR4.3 3 16">4.3 DOCUMENTATION COST</A>
<BR>
<A HREF="procure2.html#HDR4.4 3 16">4.4 INTERPRETING THE TCSEC</A>
</UL>
<A HREF="procure2.html#HDR5 2 17"><B>5 STANDARD SOLICITATION LANGUAGE</
B></A>
<BR>
<A HREF="procure2.html#HDR 2 17"><B>RFP SECTION C -- DESCRIPTIONS/
SPECIFICATIONS/STATEMENTS OF WORK</B></A>
<BR>
<A HREF="procure2.html#HDR 2 17"><B>C.1 SCOPE OF CONTRACT (AUTOMATED
INFORMATION SYTEM -- EQUIPMENT, SOFTWARE AND MAINTENANCE)</B></A>
<BR>
<A HREF="procure2.html#HDR 2 18"><B>C.2 DETAILED SPECIFICATIONS</B></A>
<BR>
<A HREF="procure2.html#HDR 2 18"><B>C.2.1 DISCRETIONARY ACCESS CONTROL
SPECIFICATIONS</B></A>
<BR>
<A HREF="procure2.html#HDR 2 19"><B>C.2.2 OBJECT REUSE SPECIFICATIONS</B></A>
<BR>
<A HREF="procure2.html#HDR 2 20"><B>C.2.3 LABELS SPECIFICATIONS</B></A>
<BR>
<A HREF="procure2.html#HDR 2 21"><B>C.2.4 LABEL INTEGRITY SPECIFICATIONS</B></
A>
<BR>
<A HREF="procure2.html#HDR 2 21"><B>C.2.5 EXPORTATION OF LABELED INFORMATION
SPECIFICATIONS</B></A>
<BR>
<A HREF="procure2.html#HDR 2 22"><B>C.2.6 EXPORTATION TO MULTILEVEL DEVICES
SPECIFICATIONS</B></A>
<BR>
<A HREF="procure2.html#HDR 2 22"><B>C.2.7 EXPORTATION TO SINGLE--LEVEL DEVICES
SPECIFICATIONS</B></A>
<BR>
<A HREF="procure2.html#HDR 2 23"><B>C.2.8 LABELING HUMAN--READABLE OUTPUT
SPECIFICATIONS</B></A>
<BR>
<A HREF="procure2.html#HDR 2 23"><B>C.2.9 SUBJECT SENSITIVITY LABELS
SPECIFICATIONS</B></A>
<BR>
<A HREF="procure2.html#HDR 2 23"><B>C.2.10 DEVICE LABELS SPECIFICATIONS</B></
A>
<BR>
<A HREF="procure2.html#HDR 2 24"><B>C.2.11 MANDATORY ACCESS CONTROL
SPECIFICATIONS</B></A>
<BR>
<A HREF="procure2.html#HDR 2 24"><B>C.2.12 IDENTIFICATION AND AUTHENTICATION
SPECIFICATIONS</B></A>
<BR>
<A HREF="procure2.html#HDR 2 26"><B>C.2.13 TRUSTED PATH SPECIFICATIONS</B></A>
<BR>
<A HREF="procure2.html#HDR 2 26"><B>C.2.14 AUDIT SPECIFICATIONS</B></A>
<BR>
<A HREF="procure2.html#HDR 2 27"><B>C.2.15 SYSTEM ARCHITECTURE
SPECIFICATIONS</B></A>
<BR>
<A HREF="procure2.html#HDR 2 28"><B>C.2.16 SYSTEM INTEGRITY SPECIFICATIONS</
B></A>
<BR>
<A HREF="procure2.html#HDR 2 29"><B>C.2.17 COVERT CHANNEL SPECIFICATIONS</B></
A>
<BR>
<A HREF="procure2.html#HDR 2 30"><B>C.2.18 TRUSTED FACILITY MANAGEMENT
SPECIFICATIONS</B></A>
<BR>
<A HREF="procure2.html#HDR 2 30"><B>C.2.19 TRUSTED RECOVERY SPECIFICATIONS</
B></A>
<BR>
<A HREF="procure2.html#HDR 2 31"><B>C.2.20 OPERATIONAL SECURITY
SPECIFICATIONS</B></A>
<BR>
<A HREF="procure2.html#HDR 2 32"><B>C.3 STATEMENTS OF WORK </B></A>
<BR>
<A HREF="procure2.html#HDR 2 32"><B>C.3.1 COVERT CHANNEL ANALYSIS STATEMENT OF
WORK</B></A>
<BR>
<A HREF="procure2.html#HDR 2 33"><B>C.3.2 TRUSTED RECOVERY STATEMENT OF WORK</
B></A>
<BR>
<A HREF="procure2.html#HDR 2 34"><B>C.3.3 SECURITY TESTING STATEMENT OF WORK</
B></A>
<BR>
<A HREF="procure2.html#HDR 2 35"><B>C.3.4 DESIGN SPECIFICATION AND
VERIFICATION STATEMENT OF WORK</B></A>
<BR>
<A HREF="procure2.html#HDR 2 36"><B>C.3.5 CONFIGURATION MANAGEMENT STATEMENT
OF WORK</B></A>
<BR>
<A HREF="procure2.html#HDR 2 37"><B>C.3.6 TRUSTED DISTRIBUTION STATEMENT OF
WORK</B></A>
<BR>
<A HREF="procure2.html#HDR 2 37"><B>C.3.7 SECURITY FEATURES USER'S GUIDE
STATEMENT OF WORK</B></A>
<BR>
<A HREF="procure2.html#HDR 2 38"><B>C.3.8 TRUSTED FACILITY MANUAL STATEMENT OF
WORK</B></A>
<BR>
<A HREF="procure2.html#HDR 2 40"><B>C.3.10 DESIGN DOCUMENTATION STATEMENT OF
WORK</B></A>
<BR>
<A HREF="procure2.html#HDR 2 41"><B><B>RFP SECTION F -- DELIVERIES AND
PERFORMANCE</B></B></A>
<BR>
<A HREF="procure2.html#HDR 2 44"><B><B>RFP SECTION J -- LIST OF DOCUMENTS,
EXHIBITS AND OTHER ATTACHMENTS</B></B></A>
<BR>
<A HREF="procure2.html#HDR 2 44"><B><B>RFP SECTION L -- INSTRUCTIONS,
CONDITIONS, AND NOTICES TO OFFERORS</B></B></A>
<BR>
<A HREF="procure2.html#HDR 2 48"><B><B>RFP ATTACHMENT A - CONTRACT DATA
REQUIREMENTS LIST (CDRL) FORM DD1423</B></B></A>
<BR>
<A HREF="procure2.html#HDR 2 48"><B><B>RFP ATTACHMENT B - GLOSSARY</B></B></A>
<BR>
<A HREF="procure2.html#HDR 2 49"><B><B>RFP ATTACHMENT C - ACRONYMS</B></B></A>
<BR>
<A HREF="procure2.html#HDR 2 50"><B><B>RFP ATTACHMENT D - REFERENCES</B></B></
A>
<BR>
<A HREF="procure2.html#HDR 2 51"><B><B>APPENDIX A BIBLIOGRAPHY</B></B></A>
</UL>
<HR><!-- This file was created with the fm2html filter.The filter is copyright
Norwegian Telecom Research andwas programmed by Jon Stephenson von
Tetzchner. -->NCSC-TG-024<p>
Volume 2/4<p>
Library No S-239,689<p>
Version 1<p>
<H2><A NAME="HDR 2 6"><B>FOREWORD</B></A></H2>
This guideline, Volume 2 of 4 in the Procurement Guideline Series, is
written to help facilitate the acquisition of trusted computer systems in
accordance with DoD 5200.28-STD, Department of Defense Trusted Computer System
Evaluation Criteria. It is designed for new or experienced automated
information system developers, purchasers, or program managers who must
identify and satisfy requirements associated with security-relevant
acquisitions. Volume 2 addresses the way by which trusted computer system
evaluation criteria are translated into language for use in the Request for
Proposal Specifications and Statements of Work.<p>
Information contained within the Procurement Guideline Series will
facilitate subsequent development of procurement guidance for the
"Federal Criteria." This series also includes information being
developed for certification and accreditation guidance.<p>
The business of computers, security, and acquisitions is complex and
dynamic. As the Director, National Computer Security Center, I invite your
recommendations for revision to this technical guideline. Our staff will
work to keep this guideline current. However, experience of users in the field
is the most important source of timely information. Please send comments and
suggestions to:<p>
National Security Agency<p>
9800 Savage Road<p>
Fort George G. Meade, MD 20755-6000<p>
ATTN: Standards, Criteria, and Guidelines Division<p>
30 June 1993<p>
Patrick R. Gallagher, Jr.<p>
Director<p>
National Computer Security Center<p>
<H2><A NAME="HDR 2 7"><B>ACKNOWLEDGMENTS</B></A></H2>
This document has been produced under the guidance of U.S. Army Major Melvin
L. DeVilbiss, assisted by Captain Michael Gold, Captain Scott M. Carlson and
Mary Whittaker, from the National Security Agency (NSA). This version of
this document was developed by Howard L. Johnson, Information Intelligence
Sciences, Inc. Reviewing organizations supporting this effort, besides many
NSA organizations, included: Contel Federal Systems; CTA, Inc; DCA; DLA;
DOE; Grumman Data Systems; GSA; MITRE; USA, CECOM; USA, OSA; USAF, USCINCPAC/
C3; USAF, AFCC; USAF, AFCSC; USMC; USN, ITAC; USN, NCTC; and USN, NISMC.
Individuals in these organizations gave generously of their time and expertise
in the useful review and critique of this document.<p>
<B>LIST OF FIGURES</B><p>
Figure 2-1 Security Related Areas 5<p>
<B>LIST OF TABLES</B><p>
Table 1 Procurement Guideline Series 1<p>
Table 2 RFP Organization 7<p>
Table 3 Data Deliverables 37<p>
<H2><A NAME="HDR1 2 8">1 GENERAL INFORMATION</A></H2>
<H3><A NAME="HDR1.1 3 8">1.1 INTRODUCTION </A></H3>
The National Security Agency (NSA) wants to clarify the computer security
aspects of the Department of Defense (DoD) automated information system
(AIS) acquisition process. Therefore, it is producing a four volume
guideline series (referenced in Table 1 and more complete titles in the
Bibliography). This document is the second volume. These guidelines are
intended for Federal agency use in acquiring trusted systems.<p>
<pre>
<B>Table 1: <B>Procurement Guideline Series</B></B>
------------------------------------------------------------------------------
------------
A<I>n Introduction to Procurement Initiators on Computer Security
Requirements, December
1992.</I>
<I>Language for RFP Specifications and Statements of Work---An Aid to
Procurement Initiators
(this guideline).</I>
Computer Security Contract Data Requirements List and Data Item Descriptions
Tutorial (to be published in 1993).
How to Evaluate a Bidder's Proposal Document---An Aid to Procurement
Initiators
<U>and Contractors (to be published in 1993).</U>
------------------------------------------------------------------------------
------------
</pre>
DoD Directive 5200.28, Security Requirements for Automated Information Systems
(AISs), provides security requirements concerning all protection aspects of
automated information systems. It specifies DoD 5200.28-STD, DoD Trusted
Computer System Evaluation Criteria (TCSEC), as the requirement source for
trusted computer systems. The second page of DoD 5200.28-STD states:
"This document is used to provide a basis for specifying security
requirements in acquisition specifications."<p>
<H3><A NAME="HDR1.2 3 8">1.2 PURPOSE</A></H3>
The intended user of the document is the "procurement initiator," to
include Program Managers, users, and security managers. These individuals must
write the Request for Proposal (RFP), specifically Section C; and the
Specification and Statement of Work (SOW). Volume 1 of this guideline series
discusses the responsibilities of different roles in procurement initiation.
<p>
The purpose of this document is to facilitate the contracting process, provide
uniformity in competitive acquisitions, minimize procurement cost and risk,
avoid delays in the solicitation process, and help ensure the solicitation
is complete before its issuance.<p>
<H4><A NAME="HDR1.2.1 4 8">1.2.1 FACILITATING THE CONTRACTING PROCESS</
A></H4>
This guideline provides Specification and Statement of Work contract
language to procure a trusted system, hopefully satisfied by a product from
the NSA Evaluated Product List (EPL). (Note: The EPL is found in the
Information Systems Security Products and Services Catalogue.) This
guideline does not address Government certification and accreditation tasks.
The guideline is written to ensure the selected system will provide adequate
security, while avoiding a costly solution. This document has no intent beyond
the security aspects of the system.<p>
DoD agencies should use this document whenever considering the acquisition
of trusted computer systems. System security requirements are provided in
contract language for direct incorporation into an RFP. The language
duplicates the words and intent of the TCSEC.<p>
<H4><A NAME="HDR1.2.2 4 9">1.2.2 FACILITATING FAIRNESS IN COMPETITIVE
ACQUISITION</A></H4>
The guidelines in this document support the procurement of EPL products and
can only be implemented if the requirements for fair competition are
satisfied. If these requirements have not been satisfied, the procurement
can result in a protest and the selection may possibly be nullified. These
requirements include:<p>
a. Public Law 98-369, "Competition in Contracting Act of 1984."<p>
b. Title 41, United States Code, Section 418, "Advocates for
Competition."<p>
c. Title 10, United States Code, Section 2318, "Advocates for
Competition."<p>
d. DoD Instruction 5000.2, Defense Acquisition Management Policy, February 23,
1991, pp. 5-A-2 through 4.<p>
e. DoD 5000.2-M, Defense Acquisition Management Documentation and Reports,
February, 1991, p. 4-D-1-3 d.(1).<p>
<H4><A NAME="HDR1.2.3 4 9">1.2.3 MINIMIZING PROCUREMENT COST AND RISK</
A></H4>
Version 1 of this procurement guideline series is written solely to acquire
products on the EPL, that is, to enable the procurement initiator to obtain
those EPL products available for integration into an application, as opposed
to developing a system through specification.<p>
For solutions that use EPL products, not only have the specifications of the
evaluated Division/Class been satisfied, but the assurance tasks have been
completed and the required documentation produced. Certification evidence,
analyses, and operational documents previously produced for an NSA
evaluation may be available to ensure trustworthiness and used directly for
certification and satisfaction of required proposal and contract data. The
results are less development risk and a lower overall cost to the bidder
and, consequently, to the Government.<p>
For a defined entity of a system to be regarded as secure in the TCSEC sense
means that, at a minimum, all of the requirements of some specified TCSEC
Division/Class must be met. This is discussed further in Volume 1, Chapter
3. To call that entity, for example, a Class B2 entity, would require NSA
evaluation as a product satisfying the Class B2 criteria. (This convention has
evolved over the past several years so that products would not be
misrepresented in their evaluation status.)<p>
A successful certification evaluation of an entity (which has not been
placed on the NSA EPL) can only state that evaluation and approval have been
completed as part of a certification process against the Class B2 set of
requirements.<p>
The rationale for this approach is as follows:<p>
a. Although a Division/Class of the TCSEC is used as the basis for the
secure part of a system, the procurement and build process can introduce
new, conflicting requirements and relax, reinterpret, or change the intent
of some of the existing TCSEC requirements. Only an exact evaluation can
determine this.<p>
b. The certification evaluation process addresses the needs of a single
implementation. It has generally not experienced the finely honed expertise of
the NSA evaluation process and personnel and does not have the same
assurance for additional applications as does an EPL product.<p>
If there are fewer than five items on the EPL meeting the stated
requirements (not just security requirements), the RFP will not dictate that
an item come from the EPL. Also, the process for placement on the EPL is
itself a restricted, Government controlled process. To state such a
requirement in the RFP would constitute a discrimination against other vendors
desiring to bid. It also cannot be stated that, for example, "a B2 system
is required" because that implies the solution must be taken from the
EPL. Therefore, the specific TCSEC requirements necessary to meet a certain
Division/Class rating must be spelled out, without stating that the B2 product
is desired. However, the desire for decreased risk and cost (common to EPL
products) is normally a strong factor for source selection.<p>
<H4><A NAME="HDR1.2.4 4 10">1.2.4 ENSURING THE SOLICITATION IS COMPLETE
BEFORE ISSUANCE</A></H4>
If we try to use the TCSEC criteria as RFP requirements in existent form,
it is found that those TCSEC criteria are not presented in the same form and
order required by the RFP. The TCSEC mixes system specifications, work
statements and products to be delivered. This guideline organizes the TCSEC
requirements into an RFP format. <p>
<H3><A NAME="HDR1.3 3 10">1.3 SCOPE</A></H3>
This guideline reformates and reorders the requirements into a form suitable
for use in contractual documents and does not revise the words in DoD 5200.28-
STD. This document might be thought of as an adaptation of the TCSEC for
procurement. Procurement considerations are documented within the guideline to
advise the procurement initiator of factors that may influence procurement
decisions, including cost control. All of the factors are addressed as
possible augmentations to the specification language provided. <p>
This set of four acquisition documents is not to be misunderstood as DoD
policy when it comes to addressing the situation of acquiring complex
systems composed of many heterogeneous components. The reason is that the
DoD policy has not been finalized that addresses systems with combinations
of EPL products and "built and certified" system entities, which may
or may not use Division/Class criteria as requirements from DoD 5200.28-
STD.<p>
What will be required for more complicated systems will be a policy for
integrating entities, to include determining interface requirements and global
policies to be supported across entities. As soon as these composition
policies are issued by the DoD, this guideline series will be updated to
reflect policy changes. In the meantime, for Program Managers faced with the
more complicated situations not currently dealt with in this series, it is
hoped that the principles of these guidelines can be extrapolated, using
guidance from the NCSC-TG-005, Trusted Network Interpretation (TNI) of the
Trusted Computer System Evaluation Criteria (TCSEC); NCSC-TG-021, Trusted
Database Management System Interpretation (TDI) of The Trusted Computer System
Evaluation Criteria; and NCSC-TG-009, Computer Security Subsystem
Interpretation (CSSI) of the Trusted Computer System Evaluation Criteria.<p>
<H3><A NAME="HDR1.4 3 11">1.4 BACKGROUND</A></H3>
A Federal Government awareness of the lack of guidance in the security arena
led to the formation of the DoD Computer Security Evaluation Center (later the
National Computer Security Center). The Trusted Product Evaluation Program
(TPEP) was started to provide an "independent laboratory" assessment
of commercial products.<p>
The TCSEC was published in 1983 and revised to become a DoD standard in
December 1985 to provide criteria for evaluating security features and
assurance requirements available in "trusted, commercially available,
automatic data processing systems."<p>
The process for acquiring trusted systems is slightly different than other
acquisitions. The major differences are that 1) the security requirements
may become a major constraining factor in determining the solution needed to
meet the remaining requirements and 2) there exists a void of acquisition
guidance for AIS security.<p>
The challenge for the procurement initiator is to specify the requirements
with sufficient clarity and flexibility to achieve the desired security
functions without limiting the ingenuity and ability of the offerors to supply
a compliant overall solution.<p>
<H2><A NAME="HDR2 2 11">2 PROCUREMENT PROCESS</A></H2>
The procurement process is governed by policy. Here three types of policy
are distinguished. The first kind of policy is referred to simply as
security policy or regulatory policy. This is security policy that applies
to all DoD systems, personnel, and operations. Next, computer security
policy or COMPUSEC policy is represented by the Division/Class criteria in the
TCSEC. Finally, operational security policy is that security policy associated
with a given application including range of classifications, range of
clearances, categories, mode, and other specific operational security
decisions that are made. Operational security policy determines which
Division/Class should be used.<p>
The procurement process begins with various Government personnel determining
operational requirements. Personnel include, but are not limited to, mission
users, Program Managers, and acquisition representatives. The primary goals
during this phase include determining the Division/Class and mode of
operation, as well as identifying the required security features and
assurances.<p>
Selection of these security specifications requires a clear understanding of
the system users' operational and mission needs, the relevant DoD security
policies, available technologies, and the system's operational environment.
Procurement initiators and offerors must also consider the security--related
areas listed in Figure 2-1 below. More detailed information concerning these
security areas can be found in DoD 5200.1-R, DoD Directive 5200.28, and DoD
5200.28-M.<p>
Physical Security<p>
Communications Security<p>
Procedural Security<p>
Emission Security<p>
Personnel Security<p>
The Designated Approving Authority (DAA) is responsible under Enclosure 4 of
DoD Directive 5200.28 to determine the minimum AIS computer--based security
requirements for the mission profile of the system being acquired. Any
adjustments to computer security evaluation Division/Class (per step 6 of
enclosure 4) will have been completed prior to using this guideline. The
Division/Class that results from this assessment may be changed based on other
factors considered by the DAA. The final Division/Class assigned to the system
will be used to isolate the appropriate section of the evaluation criteria
in the TCSEC, (which is organized by Division/Class).<p>
Later in Chapter 5 of this document, we will address specific protection
topics in the TCSEC. The paragraph will be used that corresponds to the
Division/Class being supported in this procurement. Chapter 5 will identify
both Division/Class and the corresponding TCSEC paragraph number to assist the
procurement initiator in construction of the RFP.<p>
Working with acquisition personnel, the procurement initiators should
consult this guideline using the Division/Class selected for the system. The
specification language contained in or referenced by this guideline can be
applied directly to selected features and assurances. The statements can be
amplified to meet specific operational requirements. Procurement initiators
and acquisition personnel must ensure that the security specifications and
work statements in Section C of the RFP allow EPL solutions, do not preclude
other solutions, and are compliant with the DAA's accreditation
requirements. NSA is eager to help in this determination. The requirements
of the TCSEC will be carried through the development life cycle of the system:
RFP, contract, test, certification, and accreditation. <p>
<H2><A NAME="HDR3 2 13">3 REQUEST FOR PROPOSAL</A></H2>
The RFP is the focus of this procurement guideline series. A standard RFP
has thirteen sections, each designated by a letter of the alphabet (see
Table 2). The procurement initiator provides input to and review of all of
these sections. The majority of the procedural information is controlled
directly by the procurement activity. Security relevant sections important to
the procurement initiator and addressed in the remainder of this document
are highlighted.<p>
<B>Table 2: RFP Organization</B><p>
<PRE>
<B>Letter Section Title</B>
A Solicitation/Contract Form,Standard Form 33
B Supplies or Services with Prices and Costs
C Descriptions/Specifications/Statement of Work
D Packaging and Marking
E Inspection and Acceptance
F Deliveries and Performance
G Contract Administration Data
H Special Contract Requirements
I Contract Clauses
J List of Documents,Exhibits and Other
Attachments
K Representations,Certifications and Other
Statements of Offerors or Quoters
L Instructions, Conditions, and Notices to
Offerors
M Evaluation Factors for Award
</PRE>
<H3><A NAME="HDR3.1 3 13">3.1 SECTION C - DESCRIPTIONS/SPECIFICATIONS</
A></H3>
The first part of Section C describes the technical requirements to the
offeror, including the security requirements. The section is mission user-
oriented, and will normally contain a Specification or Requirements section
that lays out the features and capabilities to included in the system to
satisfy mission security requirements. The guideline has consolidated the
security functionality requirements of the TCSEC. This will be addressed in
detail in Chapter 5.<p>
<H3><A NAME="HDR3.2 3 14">3.2 SECTION C - STATEMENTS OF WORK (SOW)</A></
H3>
The second part of Section C identifies the specific tasks the contractor will
perform during the contract period and include security related tasking. The
SOW could include tasks such as system engineering, design, and build. For
security, Statements of Work include contractor tasking necessary to achieve
specific levels of assurance, including studies and analyses, configuration
management, security test and evaluation support, delivery, and maintenance of
the trusted system. These work statements also specify the development of
the required documentation to be provided under the Contract Data Requirements
Lists (CDRLs). This will be addressed in detail in Chapter 5.<p>
<H3><A NAME="HDR3.3 3 14">3.3 SECTION F - DELIVERIES AND PERFORMANCE</A></
H3>
This section covers delivery and installation requirements. Special delivery
requirements, as specified in the TCSEC, need to be included. Performance
requirements for the trusted system will also be discussed. This section
will be addressed further in Chapter of the guideline.<p>
<H3><A NAME="HDR3.4 3 14">3.4 SECTION H - SPECIAL CONTRACT REQUIREMENTS</
A></H3>
This section of the solicitation contains clauses that are specially
tailored for each acquisition. Typical topics covered include: site access and
preparation, data rights, maintenance, liquidated damages, and training
responsibilities. Although these are not addressed specifically in this
guideline, they are often topics of concern to the procurement initiator of
trusted systems.<p>
<H3><A NAME="HDR3.5 3 14">3.5 SECTION J - LIST OF DOCUMENTS, EXHIBITS
AND OTHER ATTACHMENT</A></H3>
This section contains a list of documents, exhibits, attachments, and other
forms used to build and execute the RFP. There are usually a series of
attachments, each one dedicated to a list of specific items. Attachments
addressed by this guideline series include the following:<p>
a. The Contract Data Requirements List (CDRL). It references specific Data
Item Description (DID) requirements, which are provided in Volume 3 of the
Procurement Guideline Series and also are referenced in RFP Attachment A
contained in Chapter 5. Each SOW task is linked to one or more CDRLs; each
CDRL identifies a document or other data that the offeror is required to
deliver, along with specific information about that document (e.g. schedule,
number and frequency of revisions, distribution). Associated with each CDRL is
a DID that specifies the document's content and format. Where requirements
differ, there are unique DIDs for each Division/Class.<p>
b. Glossary. Even though it is presented separately, the glossary is an
important part of the specifications and the Statements of Work because it
precisely defines terms and further clarifies the language intent. The
glossary is included as RFP Attachment B in Chapter 5 of this guideline.<p>
c. Acronyms. Acronyms used in the RFP must be defined in their first us and
must also be identified in the accompanying acronym list. Acronyms are
included as RFP Attachment C in Chapter 5 of this guideline.<p>
d. References. References have been identified for incorporation into the
RFP. Terms support and are compatible with the specification language, and
as such, become an integral part. The references are for technical
supporting information and should not be interpreted as requirements.
References are included as RFP Attachment D Chapter 5 of this guideline. <p>
<H3><A NAME="HDR3.6 3 15">3.6 SECTION L - INSTRUCTIONS, CONDITIONS, AND
NOTICES TO OFFERORS</A></H3>
This section contains the instructions and conditions of the acquisition. It
informs offerors of their actions and responsibilities, if they are planning
to submit a proposal. It covers such things as proposal format, oral
presentations, and the proposal preparation instructions. Proposal preparation
instructions can be used to an advantage by requiring the offerors to submit
outlines of how they will conduct SOW tasking. This will assist in
understanding the offeror's technical approach and allow assessment of their
understanding of the technical requirements. This will be addressed in
detail in Chapter 5 of this guideline.<p>
<H3><A NAME="HDR3.7 3 15">3.7 SECTION M - EVALUATION FACTORS FOR AWARD</
A></H3>
This presents to the bidder the basis of award and how proposals will be
evaluated. It should be taken from the Government's proposal evaluation
criteria, addressed in Volume 4 of this guideline series.<p>
<H2><A NAME="HDR4 2 15">4 OTHER CONSIDERATIONS</A></H2>
There are other important factors to consider before the RFP language is
presented.<p>
<H3><A NAME="HDR4.1 3 15">4.1 NONMANDATORY REQUIREMENTS AND OPTIONS</A></
H3>
An alternative for procurement initiators is to specify nonmandatory
requirements. These requirements are placed in the RFP. The bidder may respond
to these requirements or choose not to respond. The bidder will not be
penalized for not responding or for proposing an unacceptable response. The
bidder can, however, gain points if the approach is deemed acceptable by the
evaluators.<p>
Nonmandatory requirements and solutions can also be proposed by the bidder
if this is allowed by the RFP. Again bidders will not be penalized for not
proposing nonmandatory requirements, for proposing unacceptable
requirements, for proposing unacceptable solutions, or for proposing
unacceptable desirable options or features. They can gain points by
proposing acceptable solutions to acceptable requirements, whether these
requirements become part of the contract or not.<p>
Options are requirements that may be proposed by the Government, but that
are not necessarily intended to be purchased at the same time as the rest of
the features. The Government may still want these options addressed in the
proposal and evaluated as if they were mandatory requirements.<p>
<H3><A NAME="HDR4.2 3 16">4.2 EVIDENCE AVAILABILITY</A></H3>
Though a vendor supplies NSA with evidence to support a product evaluation,
the Government does not necessarily have rights to that documentation. In
order to obtain certification evidence, even the identical documents
provided for product evaluation, the Government must task the development of
the documentation in the Statement of Work and delivery in the CDRL. Of
course, only that documentation that is required for certification and
operation should be specified.<p>
<H3><A NAME="HDR4.3 3 16">4.3 DOCUMENTATION COST</A></H3>
The cost for operational security documentation (e.g. Security Feature
User's Guide and Trusted Facility Manual) can be incurred within the
contract or directly by the Government. A contract cost is incurred if the
operational security documentation is specifically called out in the RFP and
therefore generated to Government standards by the offeror. The cost would
be incurred directly by the Government if the acquiring agency Program Manager
intends to develop the documentation internally. This makes the system
appear less expensive. Unfortunately, users seldom have the experience and
expertise necessary to generate this unique type of documentation. This can
lead to cost growth manifested in contract Engineering Change Proposals
(ECPs).<p>
<H3><A NAME="HDR4.4 3 16">4.4 INTERPRETING THE TCSEC</A></H3>
The philosophy of this document is to present the words of the TCSEC and
then place the responsibility for changes in the hands of the procurement
initiator, all the while warning of the pitfalls. The best approach is for the
initiator to propose changes and have them reviewed by NSA, or some other
equivalent security organization, to assess impact. Care must be taken not
to restrict potentially valid solutions when writing the specification or
Statement of Work sections of the RFP.<p>
The features and assurances for a given TCSEC Division/Class are
inseparable. If requirements or taskings are eliminated from a specific
level of trust, then that level cannot be certified. If requirements are
added, existing EPL solutions could be eliminated.<p>
The Trusted Computing Base (TCB) is the totality of protection mechanisms,
hardware, software and/or firmware, the collection of which is responsible for
enforcing security. The TCB is the trusted part, but not necessarily the
total, of the offeror's solution.<p>
<H2><A NAME="HDR5 2 17">5 STANDARD SOLICITATION LANGUAGE</A></H2>
To assist the reader, the paragraph numbering that follows is as one might
expect to find it in the RFP. This chapter identifies the language to be
used in the RFP.<p>
Certain conventions are used in this chapter. The words in bold are either
words intended for use in the RFP or references to words intended for use in
the RFP. For example, bold paragraphs normally reference specific paragraphs
of DoD 5200.28-STD that are suggested for use verbatim in the RFP document.
Paragraphs applicable to only a Division/Class range will have that range in
parentheses prior to the paragraph or group of paragraphs. Paragraphs in which
the Division/Class are absent are applicable to all Divisions/Classes (C2--
A1).<p>
Topics in Section C are divided into paragraphs as follows:<p>
a. <U>Text of the Specification or Statement of Work. These are words or
references to words suggested for inclusion in the RFP.</U><p>
b. <U>Important References. These references should be included in the RFP.
They are generally guidelines intended to explain and interpret the TCSEC
for the bidder. These references will be redundantly contained in the list
of references accompanying the RFP. It is important to emphasize that even
though these references are bold and will be contained in the RFP, they are
not RFP requirements.</U><p>
c. <U>Procurement Considerations. Here issues are discussed that have arisen
in previous procurements or are apt to arise in future procurements. These
issues should be considered by the procurement initiator in the context of
his/her particular procurement to circumvent possible later contractual or
certification problems. These considerations are not complete, but offer
guidance based on known experiences. They are not in bold and therefore we
do not automatically intend their inclusion in the RFP. Only if the
procurement initiator decides to make them requirements will they be
included in the RFP.</U><p>
The standard language and form for the trusted elements of a secure system,
along with important discussion, are provided in the remainder of this
chapter, organized according to a subset of the sections of the RFP. <p>
<H2><A NAME="HDR 2 17">RFP SECTION C -- DESCRIPTIONS/SPECIFICATIONS/STATEMENTS
OF WORK</A></H2>
<H2><A NAME="HDR 2 17">C.1 SCOPE OF CONTRACT (AUTOMATED INFORMATION SYTEM --
EQUIPMENT, SOFTWARE AND MAINTENANCE)</A></H2>
The contractor shall furnish the equipment, software, documentation, and other
contractor work required for installation and support of all items supplied
under this contract. Such items shall be supplied in conformance with the
terms and conditions of the contract. <p>
<H2><A NAME="HDR 2 18">C.2 DETAILED SPECIFICATIONS</A></H2>
Detailed technical specifications are found in this section. The glossary
and acronyms referenced in Section J and attached to this RFP are considered
to be part of this specification.<p>
<H2><A NAME="HDR 2 18">C.2.1 DISCRETIONARY ACCESS CONTROL SPECIFICATIONS</A></
H2>
Text of the Specification<p>
Where the given Division/Class is applicable, the corresponding section of the
TCSEC should be repeated in the specification portion of the RFP verbatim:<p>
<B>For Class C2, repeat TCSEC Section 2.2.1.1.</B><p>
<B>For Class B1, repeat TCSEC Section 3.1.1.1.</B><p>
<B>For Class B2, repeat TCSEC Section 3.2.1.1.</B><p>
<B>For Class B3, repeat TCSEC Section 3.3.1.1.</B><p>
<B>For Class A1, repeat TCSEC Section 4.1.1.1.</B><p>
Important References<p>
Note: References are for information only and, unless specified elsewhere, are
not to be taken as requirements.<p>
NCSC-TG-003, A Guide to Understanding Discretionary Access Control in
Trusted Systems, September 30, 1987.<p>
Discretionary Access Control Procurement Considerations<p>
Unauthorized users include both those not authorized to use the system and
legitimate users not authorized to access a specific piece of information
being protected.<p>
"Users" do not include "operators," "system
programmers," "Security Officers," and other system support
personnel. The latter are distinct from users and are subject to the Trusted
Facility Management and the System Architecture requirements. <p>
Deletion of subjects (e.g., users) and objects (e.g., data) is a potential
problem. The mechanism should handle the deletion effectively, making
certain that dangling references do not grant unintended access.<p>
The ability to assign access permissions to an object by a user should be
controlled with the same precision as the ability to access the objects
themselves. Four basic models for control exist: hierarchical, concept of
ownership, laissez--faire, and centralized. These are discussed in NCSC-TG-
003.<p>
The TCB should enforce need--to--know access restrictions placed on
information managed by the information system. The need--to--know access
restrictions for the information, when created or changed, should be
determined by the office of primary responsibility or the originator of the
information. Only users determined to have appropriate clearances in
addition to required "need-to-know" for information should be allowed to
access the information. <p>
The design must consider that discretionary access control is usually used for
both user access control and system access control. For example, the system
may contain several types of objects (known as public objects) that are
designed to be read by all users, or executed by all users, but allowing
only trusted subjects modification privileges.<p>
Discretionary access control will not stop Trojan horses. An attacker can
trick a more privileged user to run a program containing a Trojan horse that
in turn copies the user access files to the attackers address space. Trojan
horses are addressed in NCSC-TG-003.<p>
The commercial--off--the--shelf (COTS) systems may vary with respect to the
granularity of objects to which discretionary access control is applied.
Generally, they are organized to provide discretionary access control (DAC) at
the file level or at the application level. Database design can often handle
the cases when a different level of granularity is desired by the procuring
agency so that EPL products can apply. The procuring agency should take
particular care, whenever possible, to write RFP specifications for DAC that
can be met by at least some existing commercially available products. (This is
further addressed in Volume 1, Chapter 3.)<p>
<H2><A NAME="HDR 2 19">C.2.2 OBJECT REUSE SPECIFICATIONS</A></H2>
Text of the Specification<p>
<B>Where the given Division/Class is applicable, the corresponding section
of the TCSEC should be repeated in the specification portion of the RFP
verbatim:</B><p>
<B>For Class C2, repeat TCSEC Section 2.2.1.2.</B><p>
<B>For Class B1, repeat TCSEC Section 3.1.1.2.</B><p>
<B>For Class B2, repeat TCSEC Section 3.2.1.2.</B><p>
<B>For Class B3, repeat TCSEC Section 3.3.1.2.</B><p>
<B>For Class A1, repeat TCSEC Section 4.1.1.2.</B><p>
<U>Important References</U><p>
Note: References are for information only and, unless specified elsewhere, are
not to be taken as requirements.<p>
NCSC-TG-025, A Guide to Understanding Data Remanence in Automated
Information Systems, September 1991.<p>
NCSC-TG-018, A Guide to Understanding Object Reuse in Trusted Systems, July,
1992.<p>
<U>Object Reuse Procurement Considerations</U><p>
The purpose of object reuse mechanisms is to prevent disclosure of sensitive
information by ensuring that residual information is no longer available. This
objective can be achieved by clearing objects either upon allocation or
deallocatation.<p>
Object reuse is a concern when an object is not fully allocated, that is the
granularity is larger than the data. The object reuse requirement must be
satisfied based on the object size, not the data allocation.<p>
<H2><A NAME="HDR 2 20">C.2.3 LABELS SPECIFICATIONS</A></H2>
<U>Text of the Specification</U><p>
<B>Where the given Division/Class is applicable, the corresponding section
of the TCSEC should be repeated in the specification portion of the RFP
verbatim:</B><p>
<B>For Class B1, repeat TCSEC Section 3.1.1.3.</B><p>
<B>For Class B2, repeat TCSEC Section 3.2.1.3.</B><p>
<B>For Class B3, repeat TCSEC Section 3.3.1.3.</B><p>
<B>For Class A1, repeat TCSEC Section 4.1.1.3.</B><p>
<U>Important References</U><p>
(None)<p>
<U>Labels Procurement Considerations</U><p>
The tranquillity principle states that the security level of an object
cannot change while the object is being processed by a system. The same can be
stated about changes to security clearances. This is a critical area, both
from the standpoint of changes only being invocable by an authorized
individual under the direct control of the TCB and ensuring the system
cannot be spoofed when such changes are being made.<p>
Labeling of data is not used solely to control classified information. The
mandatory policy can also be used for unclassified sensitive or privacy
applications.<p>
A distinction must be made between objects that are explicitly labeled and
those that are implicitly labeled. For example, a labeled file may contain
many tuples or records mediated by the reference monitor.<p>
Internal TCB variables that are not visible to untrusted subjects need not
be labeled, provided they are not directly or indirectly accessible by
subjects external to the TCB. However, it is important to understand that such
internal variables can function as covert signalling channels when untrusted
subjects are able to detect changes in these variables by observing system
behavior.<p>
<H2><A NAME="HDR 2 21">C.2.4 LABEL INTEGRITY SPECIFICATIONS</A></H2>
<U>Text of the Specification</U><p>
<B>Where the given Division/Class is applicable, the corresponding section
of the TCSEC should be repeated in the specification portion of the RFP
verbatim:</B><p>
<B>For Class B1, repeat TCSEC Section 3.1.1.3.1.</B><p>
<B>For Class B2, repeat TCSEC Section 3.2.1.3.1.</B><p>
<B>For Class B3, repeat TCSEC Section 3.3.1.3.1.</B><p>
<B>For Class A1, repeat TCSEC Section 4.1.1.3.1.</B><p>
<U>Important References</U><p>
None<p>
<U>Label Integrity Procurement Considerations</U><p>
Care is needed when specifying the means of binding an object and its
label. A cryptographic mechanism is one of many approaches adequate to
provide assurance of the binding since the relationship and content are
preserved, and there is protection from disclosure.<p>
The form of internal sensitivity labels may differ from their external
(exported) form, but the meaning must be retained.<p>
<H2><A NAME="HDR 2 21">C.2.5 EXPORTATION OF LABELED INFORMATION
SPECIFICATIONS</A></H2>
<U>Text of the Specification</U><p>
<B>Where the given Division/Class is applicable, the corresponding section
of the TCSEC should be repeated in the specification portion of the RFP
verbatim:</B><p>
<B>For Class B1, repeat TCSEC Section 3.1.1.3.2.</B><p>
<B>For Class B2, repeat TCSEC Section 3.2.1.3.2.</B><p>
<B>For Class B3, repeat TCSEC Section 3.3.1.3.2.</B><p>
<B>For Class A1, repeat TCSEC Section 4.1.1.3.2.</B><p>
<U>Important References</U><p>
None<p>
<U>Exportation of Labeled Information Procurement Considerations</U><p>
Changes in designation should be made by a properly authorized individual,
normally the System Administrator or the Security Officer, considering the
tranquillity principle. Such changes are auditable.<p>
<H2><A NAME="HDR 2 22">C.2.6 EXPORTATION TO MULTILEVEL DEVICES
SPECIFICATIONS</A></H2>
<U>Text of the Specification</U><p>
<B>Where the given Division/Class is applicable, the corresponding section
of the TCSEC should be repeated in the specification portion of the RFP
verbatim:</B><p>
<B>For Class B1, repeat TCSEC Section 3.1.1.3.2.1.</B><p>
<B>For Class B2, repeat TCSEC Section 3.2.1.3.2.1.</B><p>
<B>For Class B3, repeat TCSEC Section 3.3.1.3.2.1.</B><p>
<B>For Class A1, repeat TCSEC Section 4.1.1.3.2.1.</B><p>
<U>Important References</U><p>
None<p>
<U>Exportation to Multilevel Devices Procurement Considerations</U><p>
The sensitivity label of an object imported to a multilevel device must be
within the range of the device and considered to be accurate by the TCB. It is
considered to be accurate because it has been protected by the security
mechanisms of the environment through which it has traversed before it reaches
the multilevel device.<p>
<H2><A NAME="HDR 2 22">C.2.7 EXPORTATION TO SINGLE--LEVEL DEVICES
SPECIFICATIONS</A></H2>
<U>Text of the Specification</U><p>
<B>Where the given Division/Class is applicable, the corresponding section
of the TCSEC should be repeated in the specification portion of the RFP
verbatim:</B><p>
<B>For Class C2, repeat TCSEC Section 2.2.1.3.2.2.</B><p>
<B>For Class B1, repeat TCSEC Section 3.1.1.3.2.2.</B><p>
<B>For Class B2, repeat TCSEC Section 3.2.1.3.2.2.</B><p>
<B>For Class B3, repeat TCSEC Section 3.3.1.3.2.2.</B><p>
<B>For Class A1, repeat TCSEC Section 4.1.1.3.2.2.</B><p>
<U>Important References</U><p>
None<p>
<U>Exportation to Single--Level Devices Procurement Considerations</U><p>
Sometimes operational use of a single level device is actually to be at one
level for a period of time and then to switch to another level. Here it is
wise to employ labels. If labels are not used, then tranquillity must be
observed during configuration change with a positive action to ensure the
level of the device is known to users and observed by the reference validation
mechanism.<p>
<H2><A NAME="HDR 2 23">C.2.8 LABELING HUMAN--READABLE OUTPUT SPECIFICATIONS</
A></H2>
Text of the Specification<p>
<B>Where the given Division/Class is applicable, the corresponding section
of the TCSEC should be repeated in the specification portion of the RFP
verbatim:</B><p>
<B>For Class B1, repeat TCSEC Section 3.1.1.3.2.3.</B><p>
<B>For Class B2, repeat TCSEC Section 3.2.1.3.2.3.</B><p>
<B>For Class B3, repeat TCSEC Section 3.3.1.3.2.3.</B><p>
<B>For Class A1, repeat TCSEC Section 4.1.1.3.2.3.</B><p>
<U>Important References</U><p>
None<p>
<U>Labeling Human--Readable Output Procurement Considerations</U><p>
The System Administrator is the "user" designated to specify the
printed or displayed sensitivity label that is to be associated with
exported information. The TCB is required to mark the beginning and end of all
human readable, paged, hard--copy output with sensitivity labels that properly
represent the sensitivity of the output. This helps users protect data they
are using.<p>
<H2><A NAME="HDR 2 23">C.2.9 SUBJECT SENSITIVITY LABELS SPECIFICATIONS</A></
H2>
Text of the Specification<p>
<B>Where the given Division/Class is applicable, the corresponding section
of the TCSEC should be repeated in the specification portion of the RFP
verbatim:</B><p>
<B>For Class B2, repeat TCSEC Section 3.2.1.3.3.</B><p>
<B>For Class B3, repeat TCSEC Section 3.3.1.3.3.</B><p>
<B>For Class A1, repeat TCSEC Section 4.1.1.3.3.</B><p>
Important References<p>
None<p>
Subject Sensitivity Labels Procurement Considerations<p>
None<p>
<H2><A NAME="HDR 2 23">C.2.10 DEVICE LABELS SPECIFICATIONS</A></H2>
Text of the Specification<p>
<B>Where the given Division/Class is applicable, the corresponding section
of the TCSEC should be repeated in the specification portion of the RFP
verbatim:</B><p>
<B>For Class B2, repeat TCSEC Section 3.2.1.3.4.</B><p>
<B>For Class B3, repeat TCSEC Section 3.3.1.3.4.</B><p>
<B>For Class A1, repeat TCSEC Section 4.1.1.3.4.</B><p>
Important References<p>
None<p>
Device Labels Procurement Considerations<p>
None<p>
<H2><A NAME="HDR 2 24">C.2.11 MANDATORY ACCESS CONTROL SPECIFICATIONS</A></H2>
Text of the Specification<p>
<B>Where the given Division/Class is applicable, the corresponding section
of the TCSEC should be repeated in the specification portion of the RFP
verbatim:</B><p>
<B>For Class B2, repeat TCSEC Section 3.2.1.4.</B><p>
<B>For Class B3, repeat TCSEC Section 3.3.1.4.</B><p>
<B>For Class A1, repeat TCSEC Section 4.1.1.4.</B><p>
TCSEC<B> Section 9.0, "A Guideline on Configuring Mandatory Access
Control Features."</B><p>
Important References<p>
None<p>
Mandatory Access Control Procurement Considerations<p>
None<p>
<H2><A NAME="HDR 2 24">C.2.12 IDENTIFICATION AND AUTHENTICATION
SPECIFICATIONS</A></H2>
Text of the Specification<p>
<B>Where the given Division/Class is applicable, the corresponding section
of the TCSEC should be repeated in the specification portion of the RFP
verbatim:</B><p>
<B>For Class C2, repeat TCSEC Section 2.2.2.1.</B><p>
<B>For Class B1, repeat TCSEC Section 3.1.2.1.</B><p>
<B>For Class B2, repeat TCSEC Section 3.2.2.1.</B><p>
<B>For Class B3, repeat TCSEC Section 3.3.2.1.</B><p>
<B>For Class A1, repeat TCSEC Section 4.1.2.1.</B><p>
Important References<p>
Note: References are for information only and, unless specified elsewhere, are
not to be taken as requirements.<p>
CSC-STD-002-85, Department of Defense (DoD) Password Management Guideline,
April 12, 1985.<p>
NCSC-TG-017, A Guide to Understanding Identification and Authentication in
Trusted Systems, September 1, 1991.<p>
Identification and Authentication Procurement Considerations<p>
This subject is discussed in Volume 1, Chapter 3 of the Procurement
Guideline Series.<p>
Technology has provided techniques and products that vary greatly in terms
of reducing attack risk while satisfying these requirements. The procurement
initiator should ensure that the solution that satisfies the requirements is
also state--of--the--art in level of protection and consistent with the
requirements of this particular application.<p>
To be effective, authentication mechanisms must uniquely and unforgeably
identify an individual. Identification and authentication data is vulnerable
to interception by an intruder interposed between a user and the TCB.
Compromise may result from mishandling off--line versions of the data (e.g.,
backup files, fault induced system dumps, or listings). Even a one--way
encrypted file can be compared with an encryption dictionary of probable
authentication data, if the encryption algorithm and key are known.<p>
(Classes B1--A1) Authorizations include functional roles assigned to
individuals. Most roles can only be occupied by one person at a time. A role
has its own set of authorizations that are normally different than the
authorizations given to the individuals who can assume the role. An individual
should not be allowed to assume a role and operate as an individual at the
same time.<p>
If passwords are to be used, an automatic password generator is strongly
recommended. If users are allowed to pick their own specific authenticators,
their behavior is stereotypical enough to permit guessing or reproducing.
Password generators are available that have been endorsed by NSA and can be
obtained as Government off--the--shelf items. <p>
Password aging is an important consideration that can be enforced
administratively or by the identification/authentication function.<p>
Smart cards and biometric approaches are effective, especially when they
augment a password approach.<p>
Whenever the subject is an operating computer program (i.e., a process),
that process shall be directly associated with just one individual user, i.e.,
the person being served by the process. If the process is a system--owned
process (e.g., a background process such as a print spooler), the person
associated with the process is generally considered to be the Security
Officer, the System Administrator, or the operator who initiated the
process. The security level and other subject data that can influence access
decisions shall be within the range of personnel security clearances
associated with the individual user. <p>
<H2><A NAME="HDR 2 26">C.2.13 TRUSTED PATH SPECIFICATIONS</A></H2>
Text of the Specification<p>
<B>Where the given Division/Class is applicable, the corresponding section
of the TCSEC should be repeated in the specification portion of the RFP
verbatim:</B><p>
<B>For Class B2, repeat TCSEC Section 3.2.2.1.1.</B><p>
<B>For Class B3, repeat TCSEC Section 3.3.2.1.1.</B><p>
<B>For Class A1, repeat TCSEC Section 4.1.2.1.1.</B><p>
Important References<p>
None<p>
Trusted Path Procurement Considerations<p>
It is important to note that the intent is to protect identification and
authentication data at the B2 level, while at the B3 and A1 levels all
intercommunications between the TCB and the user can be protected.<p>
Technology is providing products that greatly reduce the possibility of
successful attacks involving the trusted path. The procurement initiator
should ensure that the solution that satisfies the requirements is also state-
-of--the--art in level of protection.<p>
<H2><A NAME="HDR 2 26">C.2.14 AUDIT SPECIFICATIONS</A></H2>
Text of the Specification<p>
<B>Where the given Division/Class is applicable, the corresponding section
of the TCSEC should be repeated in the specification portion of the RFP
verbatim:</B><p>
<B>For Class C2, repeat TCSEC Section 2.2.2.2.</B><p>
<B>For Class B1, repeat TCSEC Section 3.1.2.2.</B><p>
<B>For Class B2, repeat TCSEC Section 3.2.2.2.</B><p>
<B>For Class B3, repeat TCSEC Section 3.3.2.2.</B><p>
<B>For Class A1, repeat TCSEC Section 4.1.2.2.</B><p>
Important References<p>
Note: References are for information only and, unless specified elsewhere, are
not to be taken as requirements.<p>
NCSC-TG-001, A Guide to Understanding Audit in Trusted Systems, June 1,
1988.<p>
Audit Procurement Considerations<p>
The option should exist that either some maximum of security related
activities be audited or that the System Administrator select events to be
audited based on overhead considerations.<p>
An audit control switch available to the System Administrator can allow
selection of audit levels, but never to allow less than some required
minimum as determined by the DAA. <p>
A requirement exists that authorized personnel shall be able to read all
events recorded on the audit trail. A selection option is required that may
either be a preselection or a post selection option. The preselection option
limits the audit data recorded. The post selection option reduces the data
analyzed from that recorded.<p>
Switches and options must not violate the requirements and intent of the
TCSEC.<p>
The audit information should be sufficient to reconstruct a complete
sequence of security related events. Audit analysis tools can greatly
enhance the efficiency of the audit control function for the System
Administrator. (See NCSC-TG-001 for further discussion.)<p>
The capability should be provided to prevent System Administrator and Security
Officer functions from turning off auditing or modifying those results. <p>
Only the System Administrator or Security Officer should be able to select
what is to be audited from other events.<p>
(Classes B3--A1) The requirement to "monitor the occurrence or
accumulation of security auditable events that may indicate an imminent
violation of security policy" is subject to interpretation. It is the
topic of an entire subfield of security known as intrusion detection. The
DAA must determine what is reasonable in the context of the particular
application.<p>
(Classes B3--A1) "If the occurrence or accumulation of these security
relevant events continues, the system shall take the least disruptive action
to terminate the event." The approach taken is very application
peculiar and the DAA must further specify the action to be taken.<p>
<H2><A NAME="HDR 2 27">C.2.15 SYSTEM ARCHITECTURE SPECIFICATIONS</A></H2>
Text of the Specification<p>
Where the given Division/Class is applicable, the corresponding section of the
TCSEC should be repeated in the specification portion of the RFP verbatim:<p>
<B>For Class C2, repeat TCSEC Section 2.2.3.1.1.</B><p>
<B>For Class B1, repeat TCSEC Section 3.1.3.1.1.</B><p>
<B>For Class B2, repeat TCSEC Section 3.2.3.1.1.</B><p>
<B>For Class B3, repeat TCSEC Section 3.3.3.1.1.</B><p>
<B>For Class A1, repeat TCSEC Section 4.1.3.1.1.</B><p>
Important References<p>
None<p>
System Architecture Procurement Considerations<p>
"Domain" as used in the TCSEC refers to the set of objects a subject
has the ability to access. It is, for example, the protection environment in
which a process is executing. Domain is sometimes also called
"context" or "address space."<p>
Protection granularity can be an issue. Finer granularity (e.g., a few
bytes) is ideal for providing precise control (down to the byte or word
level), but requires a significant amount of computer overhead to maintain.
The trade--off usually made is to have coarser granularity (e.g., 1024 byte
blocks) to reduce hardware complexity and retain acceptable performance.
(See Volume 1, Chapter 3 of this guideline series.)<p>
An important consideration is sensitivity label mapping to protection domain
mechanisms. Hardware features (usually called "keys") allow the
TCB to associate specific hardware "registers" with the main
memory areas (domains) they are protecting. There should be sufficient types
and numbers of "registers" to ensure the number of sensitivity
labels for information in the system can be adequately mapped. Common ways
to achieve these capabilities are through "Descriptor Base
Registers," "Bounds Registers," and "Virtual Memory
Mapping Registers," although other approaches may also be used.<p>
Asynchronous events are not predictable (e.g., arrival of a message, the
printer running out of paper, or communications link errors). Asynchronous
event mechanisms are hardware features that handle the unpredictable,
usually by "interrupting" the processor. Once interrupted, the
processor then deals with the event. Interpretation of DoD 5200.28-STD will
probably require hardware features that will cause the processor to
recognize and respond to specific asynchronous events, such as
"security policy violations" (in DoD 5200.28-STD phrasing,
violations of the Simple Security Property or Star Property). Unless
hardware features support these properties, software must interpret the
results of every operation, causing a severe performance penalty. The
penalty may come into conflict with mission performance requirements.<p>
<H2><A NAME="HDR 2 28">C.2.16 SYSTEM INTEGRITY SPECIFICATIONS</A></H2>
Text of the Specification<p>
<B>Where the given Division/Class is applicable, the corresponding section
of the TCSEC should be repeated in the specification portion of the RFP
verbatim:</B><p>
<B>For Class C2, repeat TCSEC Section 2.2.3.1.2.</B><p>
<B>For Class B1, repeat TCSEC Section 3.1.3.1.2.</B><p>
<B>For Class B2, repeat TCSEC Section 3.2.3.1.2.</B><p>
<B>For Class B3, repeat TCSEC Section 3.3.3.1.2.</B><p>
<B>For Class A1, repeat TCSEC Section 4.1.3.1.2.</B><p>
Important References<p>
None<p>
System Integrity Procurement Considerations<p>
System integrity requirements must be satisfied in the operational system, not
just demonstrated as part of test. The DAA shall establish the frequency
with which system integrity validation must be accomplished and it should be
incorporated into procedural security.<p>
<H2><A NAME="HDR 2 29">C.2.17 COVERT CHANNEL SPECIFICATIONS</A></H2>
Text of the Specification<p>
(Classes B2--A1) Wherever possible, covert channels identified by the covert
channel analysis with bandwidths that exceed a rate of one bit in ten
seconds should be eliminated or the TCB should provide the capability to audit
their use.<p>
Important References<p>
Note: References are for information only and, unless specified elsewhere, are
not to be taken as requirements.<p>
<B>For Class B2, TCSEC Section 3.2.3.1.3.</B><p>
<B>For Class B3, TCSEC Section 3.3.3.1.3.</B><p>
<B>For Class A1, TCSEC Section 4.1.3.1.3.</B><p>
TCSEC<B> Section 8.0, "A Guideline on Covert Channels."</B><p>
Covert Channel Procurement Considerations<p>
The TCSEC only requires the analysis of covert channels, tradeoffs involved in
restricting the channels, and identification of the auditable events that
may be used in the exploitation of known channels. Here it requires that
some action be taken for correcting them. The procurement initiator should
clearly specify in the RFP what will be expected of a contractor. Proposal
evaluation should further determine what is intended by the bidder. This issue
must be clearly understood by the Government and the bidder and documented
in the specification before an award is made.<p>
Covert channel auditing and control mechanisms can vary widely from one system
to another. In general, the ability to meet both performance and security
requirements increases as the security protection mechanisms become more
flexible.<p>
<H2><A NAME="HDR 2 30">C.2.18 TRUSTED FACILITY MANAGEMENT SPECIFICATIONS</A></
H2>
Text of the Specification<p>
<B>Where the given Division/Class is applicable, the corresponding section
of the TCSEC should be repeated in the specification portion of the RFP
verbatim:</B><p>
<B>For Class C2, repeat TCSEC Section 2.2.3.1.4.</B><p>
<B>For Class B1, repeat TCSEC Section 3.1.3.1.4.</B><p>
<B>For Class B2, repeat TCSEC Section 3.2.3.1.4.</B><p>
<B>For Class B3, repeat TCSEC Section 3.3.3.1.4.</B><p>
<B>For Class A1, repeat TCSEC Section 4.1.3.1.4.</B><p>
Important References<p>
Note: References are for information only and, unless specified elsewhere, are
not to be taken as requirements.<p>
NCSC-TG-015, A Guide to Understanding Trusted Facility Management, October 18,
1989.<p>
Trusted Facility Management Procurement Considerations<p>
The TCSEC addresses System Administrator functions and operator functions
and specifically identifies the Automated Data Processing (ADP) System
Administrator. The roles and individuals must be specifically identified for
this particular application and the RFP should show the mapping of
particular roles and those called out in the TCSEC. For example, if the
Security Officer and the ADP System Administrator are one and the same, it
should be stated or only one title should be used consistently throughout
the RFP. If there is more than one operator role, this should be
identified.<p>
The acquisition authority must carefully consider the division of functions
between the operator and the System Administrator because the cost of changing
them is often high.<p>
<H2><A NAME="HDR 2 30">C.2.19 TRUSTED RECOVERY SPECIFICATIONS</A></H2>
Text of the Specification<p>
(For B3 through A1) Based on the recommendations of a trusted recovery
decision, mechanisms shall be provided to assure that, along with
procedures, recovery without a protection compromise is obtained after a
computer system failure or other discontinuity.<p>
Important References<p>
Note: References are for information only and, unless specified elsewhere, are
not to be taken as requirements.<p>
<B>For Class B3, TCSEC Section 3.3.3.1.5.</B><p>
<B>For Class A1, TCSEC Section 4.1.3.1.5.</B><p>
NCSC-TG-022, A Guide to Understanding Trusted Recovery in Trusted Systems,
December 30, 1991.<p>
Trusted Recovery Procurement Considerations<p>
Satisfactory recovery can have significantly different meaning to different
applications because of differences in the time criticality of operational
results. The procurement initiator must be certain that the true operational
requirements for this particular application are reflected in the RFP. <p>
Note that satisfaction of this requirement does not guarantee data recovery.
It keeps the system from blindly compromising data and allows the System
Administrator to reach a known good point in the process where other mission
mechanisms (e.g., backup) can safely proceed. Trusted recovery does not
obviate the need for responsible backup procedures and practices.<p>
<H2><A NAME="HDR 2 31">C.2.20 OPERATIONAL SECURITY SPECIFICATIONS</A></H2>
Text of the Specification<p>
The bidder shall consider and/or recommend security support other than
COMPUSEC, especially physical security, emission security, and
communications security, that shall also be used to protect the system.<p>
The system shall be shown to be compatible with all operational security
requirements identified, ensuring that there is nothing in the design of the
proposed solution to preclude their satisfaction.<p>
Important References<p>
None<p>
Operational Security Procurement Considerations<p>
The procurement initiator, working with the DAA, shall specify the operational
security specifications in this section of the RFP. The following candidate
list should be considered along with any others identified:<p>
Division/Class to be satisfied.<p>
Security levels supported.<p>
Security clearances supported.<p>
Security mode(s) to be supported.<p>
Categories, compartments, and caveats supported with rules of support.<p>
Statement of all interfaces and any interface policy required to be
supported.<p>
Statement of operational positions and responsibilities of each associated
with security.<p>
Statement concerning the intended frequency of mechanism integrity checking
during operations.<p>
Minimum audit functionality to be supported at all times, plus other
increasing levels of audit support and rules for their use.<p>
Maximum number of users.<p>
Intended hours of operations.<p>
Hard copy output.<p>
Environment for software development.<p>
<H2><A NAME="HDR 2 32">C.3 STATEMENTS OF WORK </A></H2>
Detailed Statements of Work can be found in this section. The glossary and
acronyms referenced in Section J and attached to this RFP are considered to be
part of this Statement of Work.<p>
For each task, the requirements of the SOW describe the work the contractor is
expected to do. The specification of the deliverable is accomplished within
a CDRL and its associated DID. Here we have provided sample CDRL numbers to
correspond with Section F.<p>
<H2><A NAME="HDR 2 32">C.3.1 COVERT CHANNEL ANALYSIS STATEMENT OF WORK</A></
H2>
Text of the Statement of Work<p>
<B>Where the given Division/Class is applicable, the corresponding section
of the TCSEC should be repeated in the Statement of Work portion of the RFP
verbatim:</B><p>
<B>For Class B2, repeat TCSEC Section 3.2.3.1.3.</B><p>
<B>For Class B3, repeat TCSEC Section 3.3.3.1.3.</B><p>
<B>For Class A1, repeat TCSEC Section 4.1.3.1.3.</B><p>
(Classes B2--A1)<p>
The contractor shall conduct an analysis of all auditable events that may
occur in the exploitation of the identified covert channels.<p>
The contractor shall conduct an analysis of identified covert channels and
bandwidths that are non detectable by the auditing mechanisms. The
contractor shall determine the auditability of channels that have a
bandwidth in excess of one bit in ten seconds.<p>
A report of the results of these analyses shall be provided in the form of a
Covert Channel Analysis Report, written in accordance with CDRL 010.<p>
Important References<p>
Note: References are for information only and, unless specified elsewhere, are
not to be taken as requirements.<p>
TCSEC<B> Section 8.0 "A Guideline on Covert Channels."</B><p>
Covert Channel Analysis Procurement Considerations<p>
None<p>
<H2><A NAME="HDR 2 33">C.3.2 TRUSTED RECOVERY STATEMENT OF WORK</A></H2>
<U>Text of the Statement of Work</U><p>
(Classes B3--A1)<p>
<B>The contractor shall conduct an analysis of the computer system design to
determine procedures and/or mechanisms that need to be activated in case of
a system failure or other discontinuity.</B><p>
<B>Where procedures are recommended they should be thoroughly documented in
CDRL 002, Trusted Facility Manual.</B><p>
<B>Where design is recommended it is delivered in the form of system design in
accordance with CDRL 005, Formal Security Policy Model; CDRL 006,
Descriptive Top Level Specification; CDRL 008, Design Specification; and
CDRL 012, Security Test Plan.</B><p>
<U>Important References</U><p>
<B>Note: References are for information only and, unless specified
elsewhere, are not to be taken as requirements.</B><p>
<B>For Class B3, TCSEC Section 3.3.3.1.5.</B><p>
<B>For Class A1, TCSEC Section 4.1.3.1.5.</B><p>
<B>NCSC-TG-022, A Guide to Understanding Trusted Recovery in Trusted
Systems, December 30, 1991.</B><p>
<B>TCSEC Section 5.3.3, "Assurance Control Objective," p. 63.</B><p>
<U>Trusted Recovery Procurement Considerations</U><p>
None<p>
<H2><A NAME="HDR 2 34">C.3.3 SECURITY TESTING STATEMENT OF WORK</A></H2>
<U>Text of the Statement of Work</U><p>
<B>Where the given Division/Class is applicable, the corresponding section
of the TCSEC should be repeated in the Statement of Work portion of the RFP
verbatim:</B><p>
<B>For Class C2, repeat TCSEC Section 2.2.3.2.1 and TCSEC Section 10.1.</B><p>
<B>For Class B1, repeat TCSEC Section 3.1.3.2.1 and TCSEC Section 10.2.</B><p>
<B>For Class B2, repeat TCSEC Section 3.2.3.2.1 and TCSEC Section 10.2.</B><p>
<B>For Class B3, repeat TCSEC Section 3.3.3.2.1 and TCSEC Section 10.2.</B><p>
<B>For Class A1, repeat TCSEC Section 4.1.3.2.1 and TCSEC Section 10.3.</B><p>
<B>The contractor shall deliver test results in the form of Test Reports in
accordance with CDRL 014. A final summary Test Report is called out under
Section C.3.9, "Test Documentation Statement of Work."</B><p>
<U>Important References</U><p>
<B>Note: References are for information only and, unless specified
elsewhere, are not to be taken as requirements.</B><p>
<B>NCSC-TG-002, Trusted Product Evaluations: A Guide for Vendors, June 22,
1990.</B><p>
<B>NCSC-TG-019, Trusted Product Evaluation Questionnaire, May 2, 1992.</B><p>
<B>NCSC-TG-028, Assessing Controlled Access Protection, May 25, 1992.</B><p>
<U>Security Testing Procurement Considerations</U><p>
Many of the statements in the security testing requirements are subject to
interpretation, (e.g., "relatively resistant to penetration,"
"consistency with top level specifications," "no more than a
few correctable flaws," and "reasonable confidence that few
remain"). The procurement initiator in the RFP must attempt to convey
in any manner possible what will be expected by the Government, not only in
satisfying the security testing requirement, but in terms of meeting the
certification evaluation. Similarly, in evaluation of the bidder's response to
testing requirements of the RFP, the Government must be very careful to
understand that the contractor understands what is required. As an example,
there is a great advantage in identifying who will conduct the penetration
analysis (B2 and above) and how the results of that penetration will be
dealt with. A clear understanding must exist and be documented before an award
is made.<p>
<H2><A NAME="HDR 2 35">C.3.4 DESIGN SPECIFICATION AND VERIFICATION STATEMENT
OF WORK</A></H2>
<U>Text of the Statement of Work</U><p>
<B>Where the given Division/Class is applicable, the corresponding section
of the TCSEC should be repeated in the Statement of Work portion of the RFP
verbatim:</B><p>
<B>For Class B1, repeat TCSEC Section 3.1.3.2.2.</B><p>
<B>For Class B2, repeat TCSEC Section 3.2.3.2.2.</B><p>
<B>For Class B3, repeat TCSEC Section 3.3.3.2.2.</B><p>
<B>For Class A1, repeat TCSEC Section 4.1.3.2.2.</B><p>
<B>(Class B1)</B><p>
<B>Documentation developed under CDRL 004, Informal Security Policy Model, and
CDRL 008, Design Specification, shall be maintained as a result of this effort
with updates delivered according to the CDRL.</B><p>
<B>Initial delivery of CDRL 004, Informal Security Policy Model, and CDRL 008,
Design Specification, is addressed in Section C.3.10, "Design
Documentation Statement of Work." Subsequent deliveries shall be
delivered under this task.</B><p>
<B>(Class B2)</B><p>
<B>Documentation developed under CDRL 005, Formal Security Policy Model;
CDRL 006, Descriptive Top Level Specification; and CDRL 008, Design
Specification; shall be maintained as a result of this effort with updates
delivered according to the CDRL.</B><p>
<B>Initial delivery of CDRL 005, Formal Security Policy Model; CDRL 006,
Descriptive Top Level Specification; and CDRL 008, Design Specification; is
addressed in Section C.3.10, "Design Documentation Statement of
Work." Subsequent deliveries shall be delivered under this task.</B><p>
<B>(Class B3)</B><p>
<B>Documentation developed under CDRL 005, Formal Security Policy Model;
CDRL 006, Descriptive Top Level Specification; and CDRL 008, Design
Specification; shall be maintained as a result of this effort with updates
delivered according to the CDRL.</B><p>
<B>Documentation resulting from this effort shall be provided in accordance
with CDRL 009, Trusted Computing Base Verification Report.</B><p>
<B>Initial delivery of CDRL 005, Formal Security Policy Model; CDRL 006,
Descriptive Top Level Specification; and CDRL 008, Design Specification; is
addressed in Section C.3.10, "Design Documentation Statement of
Work." Subsequent deliveries shall be delivered under this task.</B><p>
<B>(Class A1)</B><p>
<B>Documentation developed under CDRL 005, Formal Security Policy Model;
CDRL 006, Descriptive Top Level Specification; CDRL 007, Formal Top Level
Specification; and CDRL 008, Design Specification; shall be maintained as a
result of this effort with updates delivered according to the CDRL.</B><p>
<B>Documentation resulting from this effort shall be provided in accordance
with CDRL 009, Trusted Computing Base Verification Report.</B><p>
<B>Initial delivery of CDRL 005, Formal Security Policy Model; CDRL 006,
Descriptive Top Level Specification; CDRL 007, Formal Top Level Specification;
and CDRL 008, Design Specification; is addressed in Section C.3.10,
"Design Documentation Statement of Work." Subsequent deliveries
shall be delivered under this task.</B><p>
<U>Important References</U><p>
<B>Note: References are for information only and, unless specified
elsewhere, are not to be taken as requirements.</B><p>
<B>NCSC-TG-014, Guidelines for Formal Verification Systems, April 1, 1989.</
B><p>
<U>Design Specification and Verification Procurement Considerations</U><p>
If there is a multifaceted policy (e.g., both mandatory access control and
discretionary access control policies), then all facets must be represented in
the Top Level Specification and Security Model.<p>
(Classes B2--A1) To broaden the audience, there is often an advantage to
requiring an informal policy model as well as a formal one.<p>
<H2><A NAME="HDR 2 36">C.3.5 CONFIGURATION MANAGEMENT STATEMENT OF WORK</A></
H2>
<U>Text of the Statement of Work</U><p>
<B>Where the given Division/Class is applicable, the corresponding section
of the TCSEC should be repeated in the Statement of Work portion of the RFP
verbatim:</B><p>
<B>For Class B2, repeat TCSEC Section 3.2.3.2.3.</B><p>
<B>For Class B3, repeat TCSEC Section 3.3.3.2.3.</B><p>
<B>For Class A1, repeat TCSEC Section 4.1.3.2.3.</B><p>
(Classes B2--A1) Prepare and deliver the TCB Configuration Management Plan
in accordance with CDRL 011. One section of this document is originated
under Section C.3.6, "Trusted Distribution Statement of Work."<p>
<U>Important References</U><p>
Note: References are for information only and, unless specified elsewhere, are
not to be taken as requirements.<p>
NCSC-TG-006, A Guide to Understanding Configuration Management in Trusted
Systems, March 28, 1988.<p>
<U>Configuration Management Procurement Considerations</U><p>
Master copies should be protected at the level of the operational data for
which it will be used.<p>
(Classes B2--A1) The maintenance of a consistent mapping between code and
documentation may require further definition (e.g., including the response
time for bringing documentation up to date with changes and the exact amount
of effort to go into this requirement).<p>
© 2022 Packet Storm. All rights reserved.
%7Cutmcsr%3D(direct)%7Cutmcmd%3D(none)){kind=small}
Follow us on Twitter
Follow us on Facebook
Subscribe to an RSS Feed