A Guide to the Procurement of Trusted Systems:
An Introduction to Procurement Initiators on
Computer Security Requirements - Volume 1 of 4
Table of Contents
NCSC-TG-024
Volume 1/4
Library No. 5-239,669
Version 1
This guideline, volume 1 of 4 in the series, "A Guide to Procurement
of Trusted Systems," 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. Information contained within
this series will facilitate subsequent development of procurement
guidance for the Federal Criteria. This series also includes information
being developed for certification and accreditation guidance. Finally,
this introductory guideline addresses both the complex acquisition
process and the many regulations, standards, and criteria to be satisfied
in providing a secure system.
There is a large body of national policy established in the form
of regulations, directives, Presidential Executive Orders, and
Office of Management and Budget (OMB) Circulars that forms the
basis for procedures to handle and process Federal information,
particularly classified information. These are presented and discussed
in Appendix A, "Historical Basis."
The business of computers, security, and acquisitions is complex
and dynamic. As the Director, National Computer Security Center,
l invite your recommendations for revision to this technical guideline.
Our staff will work to keep it current. However, experience of
users in the field is the most important source of timely information.
Please send comments and suggestions to;
National Security Agency
9800 Savage Road
Fort George G. Meade, MD 20755-6000
ATTN: Standards, Criteria, and Guidelines Division
December 1992
Patrick R. Gallagher
Director
National computer Security Center
This document has been produced under the guidance of Major (USA)
Melvin L. DeVilbiss, assisted by CPT (USA) Michael Gold and Mary
Whittaker, from the National Security Agency. Much of this document
is taken directly from "Computer Security in Acquisitions (Draft)," prepared
by the Air Force Intelligence Command (AFIC), Air Force Cryptologic
Support Center, Directorate of Securities (AFCSC/SR), under the direction
of Captain (USAF) Bob Pierce. Initial ideas for the Air Force draft
document were those of TRACOR, Inc. Interpretation and adaptation
as a DoD handbook was accomplished by Howard Johnson, Information
Intelligence Sciences, Inc.
The following organizations were particularly helpful in providing
constructive reviews and advice: Harris, Grumman Data Systems,
CTA, Inc., Seidcon, Naval Computer and Telecommunications Command,
Naval Electronic Systems Security Engineering Center, U.S. Army
Information Systems Engineering Command, GSA, MlTRE, Federal Emergency
Management Agency, and Logicon.
Special thanks to Carol Oakes, Senior Technical Editor, MITRE,
for her assistance with final editing of this guideline.
ii
LIST OF FIGURES
Figure 1-1 How to Use This Guideline.... 2
Figure 1-2 Layers of Regulation 3
Figure 2-1 Key Interactions 9
Figure 3-1 Trusted Computer System Evaluation Criteria 24
Figure 3-2 Security Protection in the Software Development Process
31
Figure 6-1 Certification and Accreditation Processes 65
Figure 7-1 Acquisition Milestones and Phases 88
LIST OF TABLES
Table 1-1 Procurement Guideline Series 1
Table 1-2 Guideline Overview 4
Table 2-1 RFP Organization 18
Table 3-1 Division D, Minimal Protection 24
Table 3-2 Division C, Discretionary Protection 25
Table 3-3 Division B, Mandatory Protection 25
Table 3-4 Division A, Verified Protection 26
Table 4-1 Security Modes and Minimum Division/Class 45
Table 4-2 Input to the System Threat Assessment Report (STAR)
48
Table 4-3 Suggested Changes and Additions to the DoD 5000.2-M
STAR Guidance to Adapt to AISs 49
Table 5-1 DT&E Objectives 56
Table 5-2 OT&E Objectives 57
Table 5-3 Desired MOE/MOP Characteristics 59
Table 6-1 Risk Management Activity 64
Table 6-2 Supporting Documentation 67
Table 6-3 Supplementary Documentation 68
Table 6-4 Data Collection Sources 70
Table 6-5 Accreditation Supporting Documentation 73
xiii
This document is a guideline designed for those who must
identify and satisfy deliverable data requirements associated with
security-relevant acquisitions of trusted, stand-alone systems. It
identifies what must be complied with, what must be read, what must
be written, and what others must be instructed to write. The detailed
acquisition process, coupled with the technical complexity of computers,
security, and contracting, represents an unsolvable mystery for many.
The goal of this document is to help clarify the complex issues.
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 the
guideline series (shown in Table 1-1), of which this document is
the first.
Table 1-1 Procurement Guideline Series
An Introduction to Procurement Initiators on Computer
Security Requirements (December 1992)
Language for RFP Specifications and Statements of Work - An
Aid to Procurement Initiators (To be published in 1993)
Computer Security Contract Data Requirements List and Data
Item Description Tutorial (To be published in 1993)
Row to Evaluate a Bidder's Proposal Document - An Aid to
Procurement Initiators and Contractors (To be published in
1993
National Computer Security Center (NCSC)-TG-004, "Glossary of Computer
Security Terms," defines security terms used in this publication.
DoD Instruction 5000.2, "Defense Acquisition Management Policies
and Procedures," defines acquisition terms. DoD Instruction 5000.33, "Uniform
Budget/Cost Terms and Definitions," defines budget terms.
This guideline is for use by all DoD agencies. It applies to AlS
developers purchasers, or program managers who deliver systems to
customers. It specifically supports acquisitions of systems from
commercial-off-the-shelf (COTS) products on the Evaluated Products
List (EPL).
Figure 1-1 shows how to use this document. The purpose of this document
is to provide the Program Manager and the Security Manager a guide
to the activities and the documentation in an acquisition of a secure
system. This document will help those responsible to develop plans
and procedures for acquisition of trusted, stand-alone systems. Specifically,
it will help identify security-relevant data to be delivered by a
contractor.
Chapter Titles Who They Should Help
General Information Introduction to Acquisition
The Acquisition Process (e.g., for security specialist)
Computer Security
Threat Risk Mgmt. Introduction to Security
Security Test & Eval. (e.g., for acquisition specialist)
Certification &
Accreditation
Guidance for Acquisition
Managing the Acquisition of of a Secure System
Secure Systems (e.g., for program and security
managers)
Figure 1-1 How to Use This Guideline
The second in this series of documents provides a way to specify security
requirements accurately in a standardized way, while complying with current
acquisition regulations. The Government decides the split of responsibility
between the Government and the Contractor. Once documents the contractor
is required to write have been identified, a Data Item Description (DID)
can be chosen from the third document in this series. If a document is
not available, the third document will also help tailor an existing DID
to create the desired DID. The fourth document in this series provides
a guide to evaluate contractor proposals addressing computer security (COMPUSEC).
The fourth guideline is intended for the procurement initiator, but will
also be helpful to the contractor preparing his/her proposal.
Most users will be building a Request for Proposal (RFP) and therefore
will need to develop deliverable data packages. The security functional
requirements must have been previously established.
The people reading this document will most likely be assigned to a Program
Management Office (PMO) or System Program Office (SPO). These organizational
elements are responsible for managing acquisition activities. The PMO/SPO
could be a several hundred person organization, or it could be just one
person. In either case, the principles and concepts are basically the same;
only the scale might change.
This set of four acquisition documents does not address the complex acquisition
of multiple security entity systems. 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, perhaps using different
division/class criteria as requirements from DoD 5200.28-STD. Strong motivation
exists to resolve the problem with an NSA-evaluated product on the EPL.
Because this resolution cannot be guaranteed, these acquisition documents
must deal with a single-system entity (called "the product" or "the system").
In this context, little difference exists between the terms "computer system" and "automated
information system," both used here. Section 3.8, "Rationale for Single
Entity Approach," presents the rationale for this approach. Chapter 5 addresses
use of the EPL.
Regulations may be written for a major system acquisition, an AlS,
a computer system, or only the software in a computer system. These
entities must be thought of as a nested hierarchy. If the scope is
a computer system, for example, then AS and major system regulations
also apply. A similar situation exists in security. Regulations deal
with information system security (INFOSEC), AlS security, and COMPUSEC.
These entities are nested when applied to applications. Considering
the system hierarchy and the security hierarchy, a situation exists
that is illustrated in Figure 1-2. Thus, requirements for a COMPUSEC
acquisition must consider, for example, DoD Instruction 5000.2, DoD
5200.1-R, DoD Directive 5200.28, Figure 1-2 Layers of Regulation
DoD-STD-21 67A, and DoD 5200.28-STD.
This guideline has seven chapters, and three appendices. Each chapter
contains pertinent references. The text focuses on the chapter's
subject, incorporating both acquisition and security. Note that Chapter
2 primarily addresses the acquisition process, although it is sometimes
placed in the context of security. Chapters 3 through 6 emphasize
security, especially in Chapter 3, which addresses security functionality.
The two topics finally merge in Chapter 7. Table 1-2 identifies chapters
and objectives.
Table 1-2 Guideline Overview
Chapter l General Information - Introduces the guideline.
Chapter 2 The Acquisition Process - Provides an overview of
the acquisition process. Identifies the major elements of financial
management. It also briefly describes the most important documents
to be referenced, produced, or requested when working on a security-related
acquisition.
Chapter 3 Computer Security - Provides insight to trusted
computing bases (TCBs) and other trusted protection. Discusses
the various TCB divisions/classes and security policy.
Chapter 4 Threat Risk Management - Analysis, Design, and Implementation
- Discusses the key aspects of risk management. Addresses the
areas of sensitivity levels, risk assessment, risk analysis,
and cost benefit analysis.
Chapter 5 Security Test and Evaluation - Addresses the full
range of ST&E, single product evaluation, project inception,
and system implementation. Also presents a simplified approach
to generating contractor test plans.
Chapter 6 Certification and Accreditation - Covers the certification
and accreditation processes. It also provides a useful list of
documents required for a complete certification or accreditation
package.
Chapter 7 Managing the Acquisition of Secure Systems - Discusses
the management policy and objectives. Identifies how to prepare
plans and conCepts. Provides an overview of all security activities
associated with the life-cycle process.
This document will not answer all the questions or solve all of the
problems encountered in an acquisition. Other sources follow.
Each chapter lists the most important references for the chapter's
subject matter. Having a personal, current copy of many of the references
is important. The documents will be referred to often. The "must
have" list, referenced below in the last section of this chapter,
is a good place to start.
Every major agency or organization has several offices that can be
of assistance:
a. Each organization usually has a security focal point. Some
offices specialize in most aspects of COMPUSEC. Start with a phone
call to the Director's office and ask for a directory or a list
of offices with names and phone numbers.
b. The investigative organization (e.g., security police) sometimes
has experts in applicable areas.
c. Each organization normally has a contracting staff and a planning
and budget management staff with expertise in the acquisition process.
d. The user should have a point of contact for the system or
project.
When SCI information is involved, consult the supporting Special
Security Officer (SSO) or Intelligence Staff Officer (ISO) within
the organization with whom the responsibility has been delegated.
The SS0 can assist with the special clearances, handling, storage,
marking, and other details required for SCI. The SSO should know
how to meet Director of Central Intelligence (DCID) 1/16, "Security
Policy for Uniform Protection of Intelligence Processed in Automated
Information Systems and Networks," and Defense Intelligence Agency
(DIAM) 50-4 "Security of Compartmented Computer Operations."
The SS0 will be able to assist in requesting an "intelligence community" threat
summary related to an individual project. See Chapter 4, "Threat
Risk Management," for more on this subject.
Other PMOs or SPOs are lucrative information sources. Contact the
program offices for information on how they have handled similar
requirements
If additional help is still needed, call or write NSA (at the address
shown in the Foreword page of this guideline). This organization
can usually put you in contact with the right person and get you
back on track.
Very few PMOs or SPOs have a complete suite of reference material.
There are, however, a few "must have" documents for all program offices.
This document listing will help those new to acquisition, who are
working on computer security in an acquisition environment. Appendix
A contains a more complete list of historical documents. Working
and agency/protection-specific bibliographies are provided in Appendix
C at the end of this document.
a. DoD 5200.1-R, "Information Security Program Regulation" -
This document is the basic DoD information security regulation,
authorized by DoD Directive 5200.1.
b. DoD Directive 5200.28, "Security Requirements for Automated
Information Systems (AISs)" - This document is the overall security
policy document for DoD AlSs that process Classified, sensitive
unclassified, or unclassified information, with the exception of
certain standalone and embedded computers.
c. DoD 5200.28-STD, "Department of Defense Trusted Computer System
Evaluation Criteria" - This document categorizes AISs into hierarchical
classes based on evaluation of their security features and assurance
for believing the security functionality has been achieved. It
is often used to help state the security requirements for any ASs
to guarantee satisfaction of a certain minimum risk level.
d. NCSC-TG-005, "Trusted Network Interpretation of the Trusted
Computer System Evaluation Criteria" - This document, also called
the "TNI," interprets the DoD 5200.28-STD for networks.
e. NCSC-TG-009, "Computer Security Subsystem Interpretation" -
This interpretation of DoD 5200.28-STD is used when a subsystem
is to be added to a protected AIS to enhance its security. This
document is useful in identifying subsystem security requirements.
f. NCSC-TG-024, Version-1 Vol. 1/4, "A Guide to Procurement of
Trusted Systems: An Introduction to Procurement Initiators on Computer
Security Requirements," (this guideline) Vol. 2/4, "A Guide to
Procurement of Trusted Systems: Language for RFP Specifications
and Statements of Work - An Aid to Procurement lnitiators," (draft)
Vol. 3/4, "A Guide to Procurement of Trusted Systems: Computer
Security Contract Data Requirements List and Data Item Description
Tutorial," (draft)
Vol. 4/4, "A Guide to Procurement of Trusted Systems: How to
Evaluate a Bidder's Proposal Document - An Aid to Procurement lnitiators
and Contractors," (draft)
g. DoD Directive 7920.1, "Life Cycle Management of Automated
Information Systems (AIS)" - This document defines life-cycle phases
and policy for AISs.
h. DOD Directive 5000.1, "Defense Acquisition" - This directive
provides policy and an overview for integrating the efforts and
products of 1) requirements generation, 2) acquisition management,
and 3) planning, programming, and budgeting systems.
i. DoD Instruction 5000.2, "Defense Acquisition Management Policies
and Procedures" - This instruction implements the regulations of
DoD Directive 5000.1 and contains DoD acquisition management policies
and procedures, replacing many past regulatory documents.
j. DoD Manual 5000.2-M, "Defense Acquisition Management Documentation
and Reports" - This manual contains procedures and formats to be
used to prepare various milestone documents and periodic status
reports.
k. DoD-STD-2167A, "Defense System Software Development" - This
software development regulation establishes requirements to be
applied during acquisition, development or support of software
standards.
i. DoD 7935-A STD, "ADS Documentation Standard" - This standard
provides guidelines for the development and revision of documents
for an automated information system.
m. "Model Framework for Management Control Over Automated Information
Systems," President's Council on Management Improvement and the
President's Council on Integrity and Efficiency, 1988 - This report
identifies 55 requirements Federal managers should follow. This
list is derived from the Financial Integrity Act of 1982, the Privacy
Act of 1974, OMB Circulars A-I 23, A-I 27, and A-I 30.
n. "Information Systems Security Products and Services Catalogue," prepared
by the National Security Agency - Complete editions are printed
in January and July. Changed chapters from the basic document are
reprinted as a supplement in April and October. A large part of
Chapter 4, in this catalogue, contains the Evaluated Products List
for Trusted Computer Systems. Many trusted system requirements
can be effectively met, using existing evaluated products from
this source document.
o. "Federal Acquisition Regulation" (FAR) and "DoD FAR Supplement."
p. Federal Information Processing Standard (FIPS) Publication
(PUB) 73, "Guidelines for Security of Computer Applications," United
States (U.S.) Department of Commerce, National Bureau (NBS) - Planning,
development and operations of Federal computing applications requires
protection because of the nature of the data or the risk and magnitude
of loss or harm. This document addresses risk analysis, objective
and vulnerability specifications, management of programming trusted
computing systems, and contingency planning.
q. "Federal Information Resources Management Regulation," (FIRMR)
General Services Administration (41 CFR 201).
THIS PAGE INTENTIONALLY LEFT BLANK
DoD acquisitions are worth billions of dollars each year. Nearly
98 percent of these acquisitions are small contracting efforts worth
less than $25,000. That accounts for only 20 percent of DoD's procurement
dollars. The other two percent of DoD's contract actions (those over
$25,000) account for 80 percent of the dollars. The large dollar
contracts bring with them a large number of people and requirements
that the program manager must deal with efficiently and effectively.
This chapter provides a brief overview of the acquisition process
and the environment one can expect to encounter. It provides information
on financial management concepts. It also introduces the major documents
to be prepared during acquisition.
DoD Directive 5000.1, Part 2, discusses three separate decision making
support systems: Planning, Programming and Budgeting (PPBS); Requirements
Generation; and Acquisition Management. (See Figure 2-1, taken from
that directive.)
Requirements Very Broad Performance Requirements
Generation Needs Objectives
System
Studies Prototyping Design & Test P
R
Acquisition Alternative Concept Stable Design O
Management Concepts Selection D
System U
Resource Requirements & Constraints C
T
I
Programming Affordability Affordability Firm Unit O
& Budgeting Goals Constraints Costs N
System
Figure 2-1 Key Interactions
PPBS is supported by three operational functions: 1) the Action Officer
(AO) is the primary advocate of a particular program. He/she develops
a Program Decision Package (PDP) and presents it to senior management.
2) The Program Element Monitor (PEM) is the functional staff advocate.
The PEM guides and monitors PDPs through the PPBS process. When a
PDP is approved, the PEM monitors and briefs its progress (e.g.,
quarterly). The AO needs to stay in contact with the PEM to ensure
the latest information is available. 3) The Resource Advisor (RA)
is the person in the SPO or PMO who monitors the use of resources
on a day-to-day basis, helps develop fund targets, and prepares the
annual budget submission.
The mission users are present in all acquisitions. They generate
mission requirements and ultimately receive and use the item or services
acquired. The user function may be represented by a functional area
expert, a major organization (e.g., agency), or even a special office.
The user sometimes maintains a liaison in the Program Office.
This function can be further divided into Program Management and
Contract Management. 1) The program management function could have
any of several names - PMO, SPO, or Program Office. In a large acquisition,
the program management function is a separate organization staffed
with specialists who are tasked to conduct the acquisition. In a
small acquisition, it could be one person. 2) A contracting function
is present in all acquisitions and usually includes a Contracting
Officer and a Buyer. The contracting function may be located within
the program management organization or within a special contracting
activity. The Contracting Officer is the ~ person authorized to obligate
the Government (i.e., negotiate, modify, and sign contracts). It
is important to seek the Contracting Officer's advice and assistance
early to avoid later problems.
A structured process of identifying financial requirements, obtaining
funds, and allocating them to competing programs (so top priorities
are satisfied) is called the PPBS. The PPBS is the official DOD resource
management system and is described in DoD Instructions 7045-7 and
7045-14. The PPBS is a complex and continuous year-round process.
It involves people from the President all the way down to individual
organizations. The PPBS operates in both a top-down and a bottom-up
mode. 1) In the top-down mode, high level DoD officials prepare policy
and strategy documents. Those documents consider the threats to the
worldwide national interests and define the strategy and objectives
necessary to counter those threats. 2) In the bottom-up mode, a particular
organization tracks every penny it spends. "Fund cites," noted on
every document, involves a financial transaction (e.g., travel orders
and contracts). The process is complicated, but it achieves visibility
and accountability for every expense. The information collected is
required by law to be rolled into successively broader accounting
Categories and used for tracking appropriations, both for historical
purposes and for planning future programs.
All acquisitions involve dealing with the information processing
industry, known as Offerors or Contractors. Their organizations have
similarities to Government organizations. They will generally have
contracting, program management, and functional (technical) personnel.
However, a business relationship with them is not the same as a working
relationship with another Government office.
Civilian corporations can track potential Government contracts using
the following sources.
Corporations can get on a mailing list at any Government contracting
office. The contracting office then sends the corporation solicitations
for the types of items or Services the corporation provides.
The Commerce Department publishes a newspaper called the "Commerce
Business Daily" (CBD). The CBD is available to civilian organizations
by subscription. Every open acquisition with an estimated value over
$25,000 must be advertised in that paper. The CBD also lists potential
subcontracting opportunities with major defense contractors. The
Program Manager normally prepares a synopsis for the Contracting
Office to submit for publication.
Smaller corporations can participate in large procurements as subcontractors.
Local contracting offices, the Commerce Business Daily, and the Small
Business Administration provide leads and contacts that small corporations
can pursue.
During source selection, the interface with the Offerors is strictly
controlled and limited to the Contracting Officer or his/her designee.
Some formal communications between the Government and the Offeror(s),
usually relate to clarifying the Offeror's proposal. Often a Government
central point of contact for technical matters is identified, known
as the Contracting Officer's Technical Representative (COTR). However,
the COTR does not have the authority to obligate the Government.
Two important meetings are conducted at contract award.
Security technology is often an eliminator in competition. This session
provides feedback for industry on how well, in general terms, their
responses met the Government's requirements. The Program Manager
should attend the debriefing and be prepared to provide "lessons
learned" from the security vantage point. This process will help
the industry representatives understand where they were responsive
and where improvements can be made. The purpose is not to recite
all the details, but to point out security strengths and weaknesses
noted in the evaluation of Offerors' proposals.
This meeting is the first formal exchange between the Government
and the successful Offeror, which is now termed the "Contractor." The
Program Manager should attend the meeting to ensure that security
issues are addressed and reflected in the minutes.
After contract award, interface with the Contractor is somewhat easier.
Keep the following issues in mind.
No one may obligate the Government except a Contracting Officer.
Specification of security is extremely difficult. What has been given
to the contractor in an RFP, or the response, may later prove to
be inadequate. The implications of a modification may be great, increasing
significantly the effort the contractor originally proposed. The
result is another negotiation -- bargaining with security and dollars
as the chips. Diluting security is not an option. Neither is overinflated
security costs. From the Government's standpoint, two solutions apply:
adequate specification in the first place or, if that has not happened,
technically astute trade-offs and cost effective technological innovation.
This is the most important time to call on security expertise.
The safest way to communicate with a Contractor is via a Technical
Interchange Meeting (TIM). A TIM is formal and requires preparation
of minutes that document the proceedings. The Contractor usually
prepares these minutes and the Contracting Officer reviews the minutes
to ensure that changes in contract scope have not been made.
The Government initiates most contract changes. Exceptions include
Contractor- proposed engineering changes. Changes may be necessary
to clarify, correct, or change requirements or schedules. All changes
require the same care and review as the original RFP.
Telephone calls, face-to-face meetings, and general correspondence
are frequently used for informal discussions of technical and administrative
matters. Both parties must be careful not to exceed the limits of
their authority. If a question arises about what may be discussed,
consult the Contracting Officer in advance.
A large number of documents must be prepared for most acquisitions.
Most can be scaled up or down according to the size, scope, and particular
needs of individual programs. Appendix B provides an overview of
the most important and widely used documents for each of the four
major areas, respectively: planning and financial management, program
management, mission user, and contracting. Appendix B includes major
references to help document preparation. Subsequent paragraphs discuss
the documents most important to the user of this guideline. These
key documents are usually required for "most" programs. Smaller programs
could either combine or reduce the size of individual documents according
to the needs of the program.
These documents provide guidance to people in the organization responsible
for conducting acquisition activities.
In the top-down mode, high-level DoD officials prepare policy and
strategy documents, which include National Security Decision Directives,
Defense Guidance, and the long-term (e.g., five year) Defense Program.
They consider the threats to worldwide national interests, and define
the strategy and objectives necessary to counter those threats.
The POM provides the response, listed in priority order, to the DoD
planning documents.
The DoD then adjusts the POM to ensure each organization's plans
are consistent with DoD guidance. The results are published as the
Program Decision Memorandum.
Budget estimate submission and final publication of the Budget are
the next steps in the process.
Appropriations are legal authority from Congress to spend dollars
on specific line items, or for specific programs. Appropriations
to an organization are the result of the budget submission, often
followed by a long negotiation process. An appropriation category
helps define how funds will be spent. Congress enacts Public Laws
to appropriate funds formally to specify these categories.
The DoD passes funds via documents called "Obligation Authorities
(OAs)." At the lowest organizational level, the target dollars an
organization has available to spend are usually distributed quarterly.
The PDP, used in conjunction with budget submissions, explains what
is needed, why it is needed, and the impact to the functional area
operational mission if the program does not receive funding. The
PDP is the basic input to the PPBS. Although the Organization responsible
for planning and financial management (e.g., Plans) writes the PDP,
Program Management input is normally solicited. The document should
be kept current. The dollar figures in the PDP must be supportable
and the words must be as compelling as the need.
These documents provide guidance to the people in the organization
responsible for conducting acquisition activities.
The PMD is the first document that authorizes a program to begin.
The Program Manager should get a copy and review it thoroughly to
determine the program participants and their roles, the basic operational
objectives, schedule and milestones, and the resources (both people
and dollars) approved by the acquiring organization. The PMD usually
identifies a series of supporting plans to be written (e.g., the
Test and Evaluation Master Plan (TEMP)). If security is a major concern,
a separate section of the PMD will address this topic.
The PMP is written in response to tasking cited in the PMD. The PMP
amplifies the roles, responsibilities, tasks, and objectives called
out in the PMD. The PMP specifically describes the organizations,
players, and assigned tasks. Like the PMD, the PMP often lists a
number of supporting plans, identifies who will prepare them, and
gives dates for submission (e.g., Human Systems Integration Plan,
Program Protection Plan, Software Development Plan, Systems Engineering
Management Plan, Technology Assessment and Control Plan, Training
and Development Plan, and Risk Management Plans). Security-relevant
issues are often described in broad terms. Based on this general
guidance, the Program Manager will prepare security- relevant chapters
or annexes for a number of support plans.
The CMP provides both high-level and detailed procedures for developing
the baseline the system and identifying, processing, and controlling
system changes. Usually, the CMP will identify a Configuration Control
Board (CCB), which is responsible for the administrative processes,
and serves as a technical body to evaluate proposed changes. As the
security focal point, the Program Manager should serve as a member
of the CCB to ensure that security-relevant issues are adequately
addressed. He/she may also be asked to evaluate changes to assess
their "security impact."
The SSP describes the Source Selection Organization, its roles, functions,
responsibilities, and the overall strategy for evaluating proposals
(the topic of volume 4 of this guideline series). Normally, the 55P
calls for several teams of people to participate in the Source Selection
Evaluation Board (SSEB). Typically, these teams will be functionally
organized, for example, responsible for technical, management, and
cost issues. The SSP also outlines award criteria and evaluation
factors along with a scoring methodology. The Program Manager should
prepare input for the security-relevant portions of the SSP. The
Program Manager may also chair the Security Panel of the Technical
Team.
Derived from the SSP, the PEG contains detailed procedures on the
SSEB's operation. The PEG describes the composition of the evaluation
teams, their subordinate panels, and their operating rules. The PEG
contains the specific evaluation standards and factors against which
Offeror proposals will be judged. The Program Manager should prepare
and coordinate the evaluation standards for security matters. Typically,
these standards would be used predominately in the Technical Area.
However, several Management Area standards must be prepared as well
(e.g., an Offeror must describe his/her compliance with DoD 5220.22-M,
the Industrial Security Manual). Above all, the Program Manager's
role in providing (or coordinating for) evaluation criteria and standards
must not be neglected. After contract award, it will be too late
to correct discrepancies or oversights without the Contractor justifiably
seeking "fair and equitable" compensation for errors. Furthermore,
it must be ensured that an Offeror is selected whose proposal best
meets the Government's requirements. The PEG is the vehicle to ensure
that outcome.
This memorandum represents approval of a particular milestone phase
and authorization for a program to move into the next milestone phase.
Baselines embody the cost, schedule, and performance objectives for
a program and should be approved by the milestone decision authority
at milestone reviews. Baselines include the Concept Baseline, the
Development Baseline, and the Production Baseline.
Like the PMD, the CRLCMP focuses on managing computer resources used
in systems throughout their individual life cycles. That is, the
CRLCMP identifies the resources, responsible supporting organizations,
and the overall strategy to ensure adequate life-cycle support is
available. Also, similar to the PMD, the CRLCMP has a subordinate
document that provides detailed support procedures. This document,
called the Computer Resources Integrated Support Document (CRISD),
describes in detail the organizational tasks and procedures for life-cycle
support of the computer resource.
As prescribed by the PMD, the TEMP is the principal source of information
for all testing activities. The TEMP describes the complete suite
of tests, the test objectives, and cites the organizations that will
participate in the testing program. Depending on the testing program
scope, the TEMP may have a separate chapter or annex that describes
security testing. The Program Manager should beCome familiar with
the TEMP and be prepared to provide test plans, test data, and test
procedures for the security-relevant concerns and issues identified
in the TEMP.
The ILSP addresses reliability, maintainability, and sustainability
for the AIS. The plan also describes the maintenance, supply, transportation,
training, packaging, and other support capabilities required to Operate
and maintain the secure AIS. The Program Manager should ensure security-relevant
issues are addressed in the ILSP (e.g., methods for shipping classified
devices to a depot for repair).
These documents describe the required Capabilities, functions, and
features of the secure AIS. Both DoD Instruction 5000.2 and DoD-STD-7935A
will be helpful in preparing these documents.
This non-system specific statement establishes a new operational
capability or improves an existing capability.
This documentation describes a full range of alternatives before
deciding to initiate a new acquisition. The justification describes
operational needs, projected threats, and plans to identify and research
alternative concepts for POM submission. This is supported by the "Federal
Information Resources Management Regulation," (FIRMR) (Code of Federal
Regulations (CFR) 201, Chapter 29) requirement to conduct a Requirement
Analysis and an Analysis of Alternatives.
A threat assessment is required for all major programs. Historically,
the STAR has not placed adequate emphasis on COMPUSEC. Identifying
the threat of malicious logic attacks (e.g., viruses, worms, and
Computer misuse) is important to the security of the system. The
STAR will also be used as input to the System Threats and Vulnerabilities
Risk Analysis required by DoD 5200.28-M. The user, or the security
expert in the PMO or SPO, should contact the intelligence function
to initiate the process. See Chapter 4, "Threat Risk Management",for
more details.
The Operational Requirements Document contains performance (operational
effectiveness and suitability) and related operational parameters.
This document describes a required capability, justifies the need,
and serves as the validation and approval document for that need.
The mission user generates this document, which identifies requirement |
