Archived NIST Technical Series Publication 

The attached publication has been archived (withdrawn), and is provided solely for historical purposes. 

It may have been superseded by another publication (indicated below). 

Archived Publication 

Series/Number: 

Title: 

Publication Date(s): 

Withdrawal Date: 

Withdrawal Note: 

Superseding Publication(s) 

The attached publication has been superseded by the following publication(s): 

Series/Number: 

Title: 

Author(s): 

Publication Date(s): 

URL/DOI: 

Additional Information (if applicable) 

Contact:

Latest revision of the 

attached publication: 

Related information: 

Withdrawal 

announcement (link): 

Date updated: ƵŐƵƐƚϭϮ, 2015 

NIST Special Publication 800-4

Computer Security Considerations in Federal Procurements: A Guide for

Procurement Initiatiors, Contracting Officers, and Computer Security

March 1992

October 2003

SP 800-4 is superseded in its entirety by the publication of

SP 800-64 (October 2003).

NIST Special Publication 800-64

Security Considerations in the System Development Life Cycle

Tim Grance, Joan Hash, Marc Stevens

October 2003

http://dx.doi.org/10.6028/NIST.SP.800-64

Computer Security Division (Information Technology Lab)

SP 800-64 Rev. 2 (as of August 12, 2015)

http://csrc.nist.gov/groups/SMA/sdlc/

N/A
NIST Special Publication 800-4

U.S. DEPARTMENT OF

COMMERCE

Technology Administration

National Institute of Standards

and Technology

NAT L INST. OF STAND 4 TECH R.I.C.

A 11 ID 3 7bDbO c

i

NIST

PUBLICATIONS

Computer Security

Considerations in

Federal Procurements:

A Guide for Procurement Initiators,

Contracting Officers, and

Computer Security Officials

Barbara Guttman

COMPUTER SECURITY

100

U57

800-4

1992

r ?

Nisr

63c too

nist special Publication soo-4 Computer Security

Considerations in

Federal Procurements:

A Guide for Procurement Initiators, c Contracting Officers, and

Computer Security Officials

Barbara Guttman

COMPUTER SECURITY

Computer Systems Laboratory

National Institute of Standards

and Technology

Gaithersburg, MD 20899

March 1992

**res o* *

U.S. DEPARTMENT OF COMMERCE

Barbara Hackman Franklin, Secretary

Technology Administration

Robert M. White, Under Secretary for Technology

National Institute of Standards and Technology

John W. Lyons, Director
Reports on Computer Systems Technology

The National Institute of Standards and Technology (NIST) has a unique responsibility for computer

systems technology within the Federal Government. NIST's Computer Systems Laboratory (CSL) develops standards and guidelines, provides technical assistance, and conducts research for computers and

related telecommunications systems to achieve more effective utilization of Federal information technology resources. CSL's responsibilities include development of technical, management, physical, and administrative standards and guidelines for the cost-effective security and privacy of sensitive unclassified

information processed in Federal computers. CSL assists agencies in developing security plans and in improving computer security awareness training. This Special Publication 800 series reports CSL re- search and guidelines to Federal agencies as well as to organizations in industry, government, and

academia.

National Institute of Standards and Technology Special Publication 800-4

Natl. Inst. Stand. Technol. Spec. Publ. 800-4, 112 pages (Mar. 1992)

CODEN: NSPUE2

U.S. GOVERNMENT PRINTING OFFICE

WASHINGTON: 1992

For sale by the Superintendent of Documents, U.S. Government Printing Office, Washington, DC 20402
EXECUTIVE SUMMARY

The Computer Security Act of 1987 (Pub. L. 100-235) and Office of Management

and Budget Circular A- 130 mandate that U.S. Government agencies protect

automated information and the resources used to process it (hardware, firmware, and

software). OMB Circular A- 130 specifically mandates that, as a part of protecting

computer systems, agencies incorporate computer security in the system acquisition

process. This NIST Special Publication provides guidance for federal procurement

initiators, contracting officers, and computer security officials on including computer

security in acquisitions.

To accomplish this goal, computer security and federal information processing (FIP)

procurement must be integrated. Computer security is the protection of the integrity,

availability and confidentiality of automated information and the resources used to

enter, store, process, and communicate the information. Computer security shares

properties with systems/software engineering including trustworthiness, system safety,

and reliability. FIP procurement is the process of acquiring hardware, software,

firmware, computer-related services and telecommunications. FIP procurement

begins with the process of determining needs and ends with contract completion.

The integration of computer security and FIP procurement will result in

improvements in:

meeting agency missions;

protecting federal assets; and

protecting individual rights.

The integration is accomplished by incorporating computer security into all phases of

the procurement cycle: planning, solicitation, source selection, and contract

administration and closeout.

This guideline is based on the collective experience of government and industry

personnel from the fields of computer security, procurement, and information

resources management and is intended to be used in conjunction with agency or General Services Administration guidance on procurement and computer security.

This guideline neither addresses nor supersedes requirements for the protection of

national security information resources.

NIST has prepared a related document that addresses the area of computer security

and procurement, Sample Statements of Work for Federal Computer Security

Services, which provides assistance to agencies that are contracting for computer

security services, such as performing a risk analysis.

iii

TABLE OF CONTENTS

Executive Summary

Preface

Working Group Participants & Contributors

I. Introduction 1 A. Requirement 1 B. Scope 1 C. Target Audience 2

D. Terminology 2

II. Background 5

A. Computer Security 5

A.l. Basic Computer Security Concepts 5

A.2. Basic Computer Security Practices 10

B. FIP Procurement 11

B. l. Basic Procurement Concepts 12

B.2. Basic FIP Procurement Practices 13

B.3. Procurement Cycle from the Procurement

Initiator's Point of View 15

EQ. Incorporating Computer Security into the Procurement

Cycle 19

A. Participants 19

B. Computer Security in the Procurement Cycle 20

B.l. Planning 20

B.l.a. Needs Determination 21

B.l.b. Requirements Analysis 22

B.l.c. Other Planning Components 27

B.2. Solicitation 28

B.2.a. Specifications and Work 29

B.2.b. Evaluation 30

B.2.c. Special Contract Requirements 32

B.3. Source Selection 33

B.4. Administration and Closeout 33
IV. Specifications, Clauses, Tasks, and Deliverables 37

A. General Computer Security 39

B. Control of Hardware and Software 40

C. Control of Information/Data 46

D. Security Documentation 48

E. Legal Issues 51

F. Administration, End of Task, Closeout 54

G. Computer Security Training and Awareness 57

H. Personnel Security 59

I. Physical Security 62

J. Computer Security Features in Systems 63

J.l. Identification and Authentication

Specifications 64

J. 2. Discretionary Access Control Specifications 65

J.3. Audit Specifications 65

J.4. Cryptography Specifications 67

J.4.a. Encryption 68

J.4.b. Data Authentication 68

J.4.C. Electronic Signature 69

J.4.d. Key Management 70

J.4.e. Security of Cryptographic Modules 71

J.4.f. Validations 72

J. 5. Object Reuse Specifications 73

J.6. System Integrity Specifications 73

J. 7. System Architecture Specifications 73

J.8. Labels and Mandatory Access Control 74

J. 9. Label Specifications 75

J.9.a. Label Integrity Specifications 75

J.9.b. Labels and Input/Output Specifications 76

J.9.b(l) Multi-Label Communications 76

J.9.b(2) Single-Label Communications 77

J.9.b(3) Labeling Output 77

J. 10. Mandatory Access Control Specifications 78

APPENDICES

Appendix A Table of Contents for Federal Government

Requests For Proposals (RFP) 79

Appendix B Assurance 83

vi
Appendix C Planning Phase Risk Analysis 91

Appendix D Glossary 95

Appendix E References 105

LIST OF FIGURES

Figure 1 Threats, Safeguards, Vulnerabilities, & Assets 7

Figure 2 Multidisciplinary Coordination 9

Figure 3 RFP Sections 15

Figure 4 Procurement Cycle 17

Figure 5 Flow Model for Computer Security Components 26

Figure 6 Computer Security in the Procurement Cycle 35

vii

PREFACE

Computers and information play an increasingly important role in modern society.

More people use computers, more information is processed and stored by them, and

our nation's dependence on computers continues to grow. Therefore, it is essential

to protect computers and the information they contain.

From a practical standpoint, computer viruses, white-collar crime, theft of hardware

and software, unauthorized access to data, and damage and destruction of computer

systems by people or nature are real threats. Computer security shows its worth in

preventing loss or harm. The meaning of terms like "appropriate and cost-effective

safeguards" are truly appreciated when explaining how a loss was or was not

prevented.

Due to the vital need to protect computer systems, the National Institute of

Standards and Technology (NIST) provides standards and guidelines on many

aspects of computer security. This document addresses the specific issue of

including computer security requirements in federal information processing (FIP)

procurements. A NIST-sponsored working group of government and industry

representatives in computer security, information management, and FIP procurement

helped to develop this document.

ix
Working Group Participants and Contributors

RonslH 1YU11CUU Rrnnnpr JJl U11UC1 IwllalU RnnalH (~i \J . Rrnnnpr 1J1U1111C1 MrOC .r\oolJvla.lCJ» A eer^idtpe

ItTq^p i nl\/Ai* ociicid.1 ociviLci> riuminisudiion

JL/UIllld. J-VUUaUll INcUlUllal IIIMUUIC Ul OUWIUaJUS OC 1 CL-IlllUlUgy

Vircril Oih<inn vji ui mi ia.il vjoxol oj iMCiiia/ in dliuiia.1 ocwuilly rtiiCllcy

Danipl IxiUIlvl Gamhpl VJ Cll 1 1 l-'^'l finimman Data SvstPiTK/Narinnal SJpniritv Acrptirv

"PL-i. T^vlrvr 1 dylUl TLu&llVll anHnun UUl vji uiiiiiictii ucLva. oyaiciiia

r^ot-olH Q T on(j vjci aiu o. i^cuig T"»f*nn iycpalrtmpnt LlllClll r\f Ul \7f*tf»r5> VClClallan c /Al Affaire 1 all

Victor Marshall R007- Allpn IJarniltnn/Natinrial Aprnnantire. Mr Snarf*

AHmi ni sIrati on

/Al> AN<sFR OJ_<lV

VJaiy Wla.ll -FCUCldl l_(lllClgCll^y IVlallagClllCIll r\UllllIllMlcUlUll

Nicholas Pantiuk Grumman Data Systems/National Security Agency

f^hinnit!! PhillinQ v. IllLjUllcl JTlllllljJo vJCllCl u.1 JClvlCCo /AUllllIlldUallUIl

Carmen Santos-Logan Defense Logistics Agency

Philip Sibert Department of Energy

Edward Simpson Department of Energy

Ted I. Wells Patent & Trademark Office

Stephen C. Willett U.S. Postal Service

John Zobel International Software Systems/Department of State

The Working Group gratefully acknowledges input from the following people:

Carol E. Bennett National Aeronautics & Space Administration

Joan Bonk U.S. Senate

Leonard Clark National Aeronautics & Space Administration

Lee Conyers Department of Transportation

Karen Deneroff Internal Revenue Service

Barbara Estrada Department of the Treasury

Irene Gilbert National Institute of Standards & Technology

Paul Lewis Department of Energy

Harris McGarrah U.S. Coast Guard

Michelle Moldenhauer Department of the Treasury

Noel Nazario National Institute of Standards & Technology

Bill O'Brian U.S. Navy

Mervyn Stuckey Bureau of the Census

X
CHAPTER I INTRODUCTION

A. REQUIREMENT

The need to provide protection for federal automated information assets has been

present since computers were first used. The Office of Management and Budget

(OMB) formally established a federal computer security policy in 1978 and updated

that policy in OMB Circular A- 130, dated December 1985. Congress passed several

laws relevant to computer security, including the Computer Security Act of 1987.

Both Congress and OMB update and revise federal policies and regulations on

computer security. Computer security concepts and practices are discussed in

section ILA, Computer Security.

In order to meet these policies and regulations, federal agencies must include

computer security considerations in all phases of information resources management.

OMB Circular A- 130 and the Federal Information Resources Management Regulation

(FIRMR) require security specifications for systems acquisitions. In general,

including computer security in the acquisition phase results in less expensive and

better security than adding security to an operational system. This document

provides guidance on including computer security considerations in the acquisition

phase of information resources management.

B. SCOPE

This document is intended to help agencies select and acquire cost-effective

computer security by explaining how to include computer security requirements in

federal information processing (FIP) procurements. The guideline has three parts.

The first part is an introduction to the two disciplines:

computer security (targeted for FIP procurement personnel); and

FIP procurement (targeted for computer security personnel).

These overviews provide sufficient knowledge to understand the legal, conceptual,

and regulatory underpinnings of the document. It should not be used as a sole

guide to computer security or FIP procurement.

1
The second part explains the integration of computer security into the FIP

procurement process. The guideline recommends that the following analyses be

included in procurement documentation:

sensitivity determination;

analysis of integrity, availability, and confidentiality requirements;

analysis of level of assurance required; and

planning phase risk analysis.

The guideline also provides assistance on the selection of computer security features,

assurances, and procedures. The guideline clarifies:

what sources of features, assurances, and procedures are required to be used

by law or regulation; and

what other sources are available and how to use them.

The third part of the document includes specifications and contract language for

specific computer security features, assurances, and procedures that can be included

in FIP procurements.

This document does not address the procurement of computer security-related

services, such as the development of risk analyses and contingency plans. NIST has

prepared a separate document, Special Publication 800-4, Sample Statements of Work

for Federal Computer Security Services, to address procurement of these services.

This document is not a substitute for agency procurement or security regulations,

policy, and guidance. It is intended to be used in conjunction with these agency

regulations. This document does not address computer security requirements for

national security or Warner Amendment information resources.

C. TARGET AUDIENCE

This document targets procurement initiators (the sponsor, program manager, or person who will become the contracting officer's technical representative),

contracting officers, and computer security officials.

D. TERMINOLOGY

The terms computer, computer system, automatic data processing (ADP), automatic

data processing equipment (ADPE), federal information processing (FIP) resource,

information technology support (ITS), information resources (IR), and automated

2
information system (AIS) are used interchangeably throughout the government. In

this document, the term FIP procurement is used because it is the term used in the

FIRMR, and the term computer security is used because it is the most common.

Both FIP procurement and computer security address the resources and services used

to enter, store, process, and transmit automated information and data.

Appendix D contains a glossary of selected computer security and procurement

terms.

3

CHAPTER II

BACKGROUND

This chapter provides a general introduction to computer security and FIP

procurement. The section on computer security is targeted for contracting officers.

The section on FIP procurement is targeted for computer security officials. The

sections are not complete step-by-step procedures, but provide background for the

rest of the guideline.

A. COMPUTER SECURITY

Computer security is the protection of the integrity, availability and, if needed,

confidentiality of automated information and the resources used to enter, store,

process, and communicate it. Computer security is often referred to in conjunction

with system trustworthiness, integrity, safety, availability, and reliability. In the

federal government, the primary policy mandates for protecting computer assets are

in OMB Circular A- 130, "Management of Federal Information Resources,"

specifically Appendix III, "Security of Federal Automated Information Systems," and

the Computer Security Act of 1987.

This section addresses basic computer security concepts and practices, based on

OMB Circular A- 130 and the Computer Security Act. Understanding these concepts

and practices helps procurement initiators and contracting officers properly integrate

computer security considerations into procurements.

A.l. BASIC COMPUTER SECURITY CONCEPTS

Several basic concepts in computer security are described below:

Management Issue. Computer security is an increasingly important issue for all federal managers. Modern technology allows federal agencies to store and process

vast amounts of data in support of agency functions. Federal computer and

information assets have great value and need to be managed to the same extent as the more traditional organizational assets (i.e., employees, money, equipment, natural

resources, and time).

Value of Information and Computing Resources. The value of federal

information and computing resources and the importance of federal agency missions

create a need for these resources to be adequately protected. Owners and users of

the information provide the impetus for protecting these valuable resources.

5
Functional Requirement. Computer security is a functional requirement of most

systems. If data is not accurate, complete, timely, available, and, if necessary,

confidential, then the system may be unable to perform its basic function.

Individual Privacy. Automated information about individuals must be protected in

accordance with the Privacy Act of 1974 and other statutes.

Life Cycle Phases. Many systems are designed, developed, and implemented over months or years. A system life cycle is used to manage a system from its inception

through its development, implementation, and operation until its termination. If

security is initially designed into a computer system, the safeguard options are vastly

increased and the security costs over the life of the system are substantially reduced.

Since the system environment and technology may change during the system life

cycle, the security will need to change also. Therefore, it is important for all managers to ensure that security is appropriately addressed in all phases of the life

cycle for computer systems, especially in the early planning stages.

Some automated systems are acquired "off-the-shelf" and can be used immediately.

In procuring these systems, initiators must consider the systems' present security

features and expandability to meet future security needs. Many vendors offer

security features on off-the-shelf systems which may be ordered separately and

installed after the system is in operation.

Computer Security Incidents. In recent years federal agencies have become aware

of more computer security incidents. These incidents result from intentional and

unintentional actions by internal (government and contractor) personnel and outsiders.

These incidents result in monetary losses and decrease an agency's productivity and

even its ability to perform its mission. While advances in computer and

telecommunications technology help prevent many problems, the difficulty of

managing the rapid change and the technical complexity can increase the federal

government's vulnerability to incidents.

Balance. Absolute security is virtually impossible. Federal agencies cannot totally

protect their computer systems from every possible threat for numerous reasons,

including the following:

Absolute protection would make the agency's systems virtually inaccessible

and unusable;

Some vulnerabilities may not be known, as in the case where application code

contains security flaws; and

6
Computer security, like other disciplines, depends on people, who are capable

of error and dishonesty.

Goal. The goal of federal computer security is to support the mission of the agency

by providing cost-effective protection that assures the integrity, availability, and

confidentiality of automated information and the resources used to process it. There are few clear rules for accomplishing this goal. Nevertheless, OMB Circular

A- 130 requires that the following types of protective measures be used, alone or in

combination, to cost-effectively provide appropriate protection:

• Technical;

• Personnel;

• Administrative;

• Environmental; and

• Telecommunications.

Figure 1 shows how protective measures, called safeguards, are used to protect

assets from threats. These safeguards can be internal or external to the system. A

threat is any circumstance or event with the potential to cause harm to a system in

the form of destruction, disclosure, modification, and/or denial of service. If a safeguard is missing or inadequate, a threat can "get through" and damage assets. The damage to the asset has an impact on the agency. The "gap" between the

safeguards is referred to as a vulnerability. The selection of safeguards for a

specific computing environment is based on an assessment of the assets, impacts,

threats, probabilities, vulnerabilities and the adequacy, availability, and cost of

safeguards. This process is called risk analysis.

AS5ET5

DATA

FACILITIES

HARDWARE/SOFTWARE

THREATS

SAFEGUARD

SAFEGUARD

VU1 NJFR ARI1 1TY

SAFEGUARD

Figure 1. Threats, Safeguards, Vulnerabilities, & Assets.
Multidisciplinary Coordination. All traditional management disciplines and

functions must be employed in a coordinated fashion to effectively manage computer

security. Over the years, federal agencies have become more dependent on

automation technologies to support all aspects of their operations and missions. As

a result, there are many security-related disciplines, each with its own set of policies

and procedures.

Figure 2 shows possible functional areas in an agency with responsibilities that

overlap with computer security. Many of these are separate career fields within the

government. Only when all disciplines are working together, in a highly coordinated

fashion, can the entire security process function properly and efficiently. Thus,

computer security managers at all levels must regularly coordinate with personnel in

other security-related disciplines.

8
Figure 2. Multidisciplinary Coordination.

9
A.2. BASIC COMPUTER SECURITY PRACTICES

In practice, certain basic actions are necessary in all federal computer security

programs. These include:

Develop Computer Security Policy/Procedures. Computer security policies and

procedures are needed to define the overall framework for implementing and

sustaining an efficient and cost-effective computer security program at the federal

agency level. The policy establishes lines of authority, roles and responsibilities,

and basic principles and requirements which define the computer security program.

The procedures contain implementation and compliance instructions and management

processes.

Institute Computer Security Planning. Computer security planning must provide a

consistent approach for determining short- and long-range management objectives,

developing security enhancement proposals, mapping proposals to budget requests,

and assuring the implementation of cost-effective protective measures.

Institute a Sensitivity Identification Process. The Computer Security Act requires

that agencies identify sensitive systems. In order to accomplish this, agencies must

institute a process for determining sensitivity.

Define and Implement a Risk Analysis Program. This program should ensure the

performance of risk analyses on agency systems. Federal managers need to

continually identify and analyze potential threats to their computing and

telecommunications environments and take action to reduce risk exposures to

acceptable levels.

Establish a Protective Measure Baseline. There are numerous combinations of

technical, personnel, administrative, environmental, and telecommunications protective

measures available to federal managers. While OMB Circular A- 130 defines a governmentwide security baseline, an organization-specific security baseline can help an agency ensure adequate protection of resources.

Ensure the Conduct of Certifications and/or Accreditations. Computer security

certifications and/or accreditations are a management control for ensuring that

installed security safeguards are adequate.

Oversee a Multi-layer Compliance Assurance Mechanism. Management and

compliance reviews should be conducted periodically to sustain optimal security

levels.

10
Develop an Incident Response and Reporting Mechanism. Agencies should

develop appropriate responses to security incidents and provide feedback information

to senior management on significant incidents. This reporting also supports the

tracking of agencywide trends.

Ensure Continuous Awareness and Training. Continuous awareness and training are necessary to elevate and sustain management and personnel awareness and to provide specific guidance for personnel who design, implement, use, or maintain

computer systems.

Ensure Contingency Planning. Contingency, disaster recovery, and continuity of

operations plans provide continued processing capability when other safeguards have

failed to maintain system reliability or availability. Such plans should be in place

and tested periodically.

Ensure Personnel Screening. Personnel who participate in managing, using,

designing, developing, operating, or maintaining computer systems should be

appropriately screened. The level of screening should be commensurate with the

loss or harm that could be caused by these individuals. This applies to both federal

and contractor personnel. The Office of Personnel Management defines screening

requirements for federal personnel.

Develop Appropriate Acquisition Requirements. In contracts for hardware,

software, and computer-related services, federal agencies must ensure that:

appropriate security requirements and specifications are included in statements

of work; and

security requirements and specifications are implemented properly before the

system goes into operation.

B. FIP PROCUREMENT

This section provides a general introduction to FIP procurement for computer

security officials. The section is not a complete "how to" but provides background

for the rest of the guideline.

The acquisition of federal information processing (FIP) resources has discrete

characteristics that distinguish it from the acquisition of other supplies or services.

FIP acquisitions have unique authority, approval, and documentation requirements.

These requirements flow from various laws and are implemented in two primary

regulations:

11
Federal Acquisition Regulation (FAR); and

Federal Information Resources Management Regulation (FIRMR).

FIP procurement, as defined by the Brooks Act, the Paperwork Reduction

Reauthorization Act, and the FIRMR, involves the acquisition of computer hardware,

software, firmware and related services including telecommunications and support

services.

The FIRMR is the primary regulation for use by federal or executive agencies in

their management, acquisition, and use of information processing resources. It is issued by the General Services Administration (GSA), which has primary

responsibility for the management of FIP resources in the federal government.

Note: This section, like the rest of the document, does not address national security

systems or systems covered by the Warner Amendment. (See glossary for a

definition of Warner Amendment systems.)

The following sections address FIP procurement concepts and practices.

B.l. BASIC PROCUREMENT CONCEPTS

It is essential to have a basic understanding of the underlying goals and objectives

of the government's procurement procedures. Without this understanding, the

procurement process can be confusing and its rules can appear intractable and

obscure. Under these conditions, it is difficult to include computer security. In

addition, because conflicts and problems sometimes arise during a procurement,

knowledge of the underlying goals and objectives will help the procurement initiator

work with the procurement staff to resolve problems.

The following analysis is a basic tutorial on the essential elements of federal

government procurement. It is not intended to substitute for the FAR, the FIRMR,

or your agency's procurement guidelines.

Federal procurement is governed by its underlying goals. These goals are:

to obtain quality products that meet the government's needs at the best price

(now and in the future);

to promote innovation and growth in American industry; and

12
to promote the social and economic development of certain segments of

American society.

The government attempts to meets its goals with certain objectives. These

objectives are derived from the goals and the fundamental nature of how the

government operates. The objectives are:

Competition. The government recognizes that competition causes offerors to

lower price and increase quality in order to win contracts. Competition is the

primary means of attaining economy and efficiency in satisfying the needs of

the government. The government recognizes that new sources must be

considered to increase the number of options, to stimulate new ideas by

providing an accessible market, and to be fair to all businesses interested in

selling to the government.

Fairness. In order to achieve meaningful competition, the government must

conduct procurements fairly. By offering all vendors and new ideas a fair

chance, the government encourages growth.

Promotion of small, minority-owned, woman-owned, and disadvantaged

businesses. The government recognizes that the socio-economic development

of these groups is to the advantage of the country. This objective is closely

related to the previous objective.

Given these diverse goals for the procurement process and the myriad individual

situations, it is possible for conflicts to arise in the process.

B.2. BASIC FIP PROCUREMENT PRACTICES

The administration of these goals and objectives in FIP procurement is governed by

laws and regulations which are implemented in the FAR, the FIRMR, and agency

regulations. While these sources contain much more information, the following is a

brief list of fundamental practices.

GSA Responsibility. GSA has authority for the management and oversight of FIP

procurement. Agencies, however, are responsible for defining their requirements.

GSA exercises its authority in a number of ways:

Delegation of Procurement Authority (DPA). GSA exercises its authority

through the use of DPAs. Without a DPA, an agency cannot acquire FIP

resources. There are three types of delegations: regulatory, specific agency,

13
and specific acquisition. GSA can withdraw or limit DPAs and can refuse to

grant DPAs until procurements conform to GSA standards.

GSA Reviews. GSA conducts periodic reviews to assess how agencies are acquiring and managing FIP resources.

General Services Board of Contract Appeals (GSBCA). The GSBCA was

created by the Competition in Contracting Act of 1984 to hear protests

relating to FIP procurement. (Contract cases can also be heard by the

General Accounting Office, the procuring agency, or the courts.) The

GSBCA can uphold or overturn procurements and can suspend an agency's

DPA.

Vendors can protest a specification or action of the government relating to a

particular procurement if the protest meets certain administrative and legal

constraints. Vendors can protest that a specification is restrictive, that the

agency does not require a certain specification, or that the government was

unfair or did not follow its procedures correctly. The protesting of

specifications has caused the government to not only identify requirements,

but also justify them.

A protest can delay a procurement for months or years and can result in an agency having to amend the solicitation or, in a worse case, issue a new

solicitation. A solicitation that is well justified by the supporting

documentation is essential to minimize protests and to lessen their duration.

Full and Open Competition. The Competition in Contracting Act of 1984 requires

the government to use full and open competition. Sometimes procurement initiators are confused about the definition of full and open competition. Full and open

competition is achieved when all responsible sources are given the opportunity to

submit a proposal and be considered.

Full and open competition is not necessarily achieved when there is more than one

source. Consideration of three products does not mean that the government can

refuse to consider a fourth responsible source. The government must consider

products from all responsive and responsible sources. (See glossary for definitions

of responsive and responsible.)

Note: There are exceptions to full and open competition that are described in

FAR 6.3.

14
B.3. PROCUREMENT CYCLE FROM THE PROCUREMENT INITIATOR'S

POINT OF VIEW

The procurement initiator is the sponsor or program manager who represents the

organization that needs the FIP resources. This person often becomes the

contracting officer's (technical) representative (COR or COTR) after award. The

procurement cycle is the progression of stages in the process of acquiring property

or services. From the procurement initiator's point of view, the procurement cycle

consists of four stages: planning, solicitation, source selection, and contract

administration and closeout.

Planning. Procurement planning can be divided into two subsections: general

planning and the specific planning for a procurement. Part 7 of the FAR provides

additional guidance on acquisition planning.

Solicitation. Solicitation refers to the process of asking vendors for proposals (also

called offers) or bids. This guideline addresses the Request for Proposals (RFP)

because it is the most common and most complex form of solicitation. There are other methods, such as the Invitation for Bids (DFB) or Request for Quotes (RFQ).

The ideas in this guideline can be used for all types of solicitations.

An RFP has 13 sections, which are generally referred to by letter. Figure 3 lists the

sections. Appendix A contains a chart describing the sections.

Letter Section Title

A Solicitation/Contract Form - Standard Form 33

B Supplies or Services and Prices and Costs

C Descriptions/Specif icat ions /Work Statement

D Packaging and Marking

E Inspection and Acceptance

F Deliveries or Performance

G Contract Administration Data

H Special Contract Requirements

I Contract Clauses

J List of Attachments

K Representations, Certifications, and Other

Statements of Offerors or Quoters

L Instructions, Conditions, and Notices to Offerors

M Evaluation Factors for Award

Figure 3. RFP Sections.

15
Source Selection. Source selection is the process of evaluating offers against

criteria stated in the solicitation and selecting the offer that best meets the

government's requirements. Source selection can involve various forms of

interactions with offerors including negotiations, clarification requests, discussions,

and best and final offers (BAFOs). It can also include performance and capability

testing. In addition, the government must notify unsuccessful offerors and debrief

them, if requested.

Contract Administration and Closeout. Contract administration refers to the

management of the contract, including inspection and acceptance of deliverables and

modification of the contract. It occurs after actual contract award. Contract

administration duties are shared by the contracting officer and the contracting

officer's technical representative (COTR). Closeout is the action that is taken when

performance under the contract is completed.

Procurement Cycle Figure. A figure showing the FIP procurement cycle from the

procurement initiator's point of view is presented in figure 4. Chapter three will

expand on the figure by incorporating computer security activities. Procurement

initiators who are unfamiliar with the procurement cycle should obtain additional

guidance from their procurement office.

Many of the actions taken by the contracting officer are not reflected in this figure.

16
PROCUREMENT CYCLE

FROM THE PROCUREMENT INITIATOR'S POINT OF VIEW

Planning

General Procurement

Specific

Solicitation Source

Selection

Administration &

Closeout

Strategic/

Tactical

Planning

Needs

Determination

Requirements

Analysis

Analysis of

Technical

Alternatives

Feasibility

Study

Cost/Benefit

Analysis

Software

Conversion

Study

Market

Study

Statement

of Work

Evaluation

Plan

Review of

Solicitation

Evaluation

of Proposals

Inspection &

Acceptance

COTR

Responsibilities

Figure 4. Procurement Cycle.

17

/

CHAPTER III

INCORPORATING COMPUTER SECURITY INTO THE PROCUREMENT

CYCLE

To effectively include computer security in the procurement process it must be

integrated into the procurement cycle from its inception. This guideline focuses on

the computer security components of the procurement cycle. Sufficient information

about the procurement cycle is included to allow a person not familiar with the

procurement process to understand the chapter. This chapter does not provide a complete description of the procurement process. (See the FAR and the FIRMR for

detailed procurement information.)

A. PARTICIPANTS

There are many participants who can have a computer security or oversight role in

procurements depending on the nature and scope of the system. These participants are listed both by type of role and by functional title. The names for the roles and

titles will vary in different organizations. Each of these does not necessarily provide

input in every phase. For instance, support contractors and vendors are restricted

from participating in some phases. The determination of which participants need to be consulted is as unique as the procurement.

The list of participating groups and offices below is not all inclusive, but does

represent many of the functions that can impact security.

Procurement Initiator/Sponsor

Functional Manager/Owner of data

Users

Procurement/Contracts

Certification/Accreditation

Computer Security

Quality Assurance/Quality Control/Safety

Legal

Information Resources Management

Design/Engineering

Budget

Audit/Internal Control

Physical/Personnel Security

Facilities/Logistics

Support Contractors/Consultants

Manufacturers/Suppliers/Vendors

19
The length of the list is indicative of the difficulty of managing and acquiring FIP

resources. It is vital that these groups work together to ensure that important

aspects of the procurement are addressed.

As with any acquisition, it is important to involve the contracting officer as early as possible, preferably in the planning stage.

B. COMPUTER SECURITY IN THE PROCUREMENT CYCLE

The purpose of this section is to define steps that will integrate computer security

into the procurement cycle. The section explains each of the computer security

steps of each phase of the procurement cycle. During the procurement cycle, the

technical and security requirements will be advanced together.

Figure 6, Computer Security in the Procurement Cycle, located at the end of this

chapter, illustrates how security fits into the procurement cycle. It expands on

figure 4 in chapter two and maps security-related activities to the procurement

activities already being performed. This chapter will explain each computer security

activity in figure 6.

The computer security steps in this section describe analyses and processes to be

accomplished. These steps define a conceptual framework for computer security

planning during the procurement cycle. This framework is intended to be used as an example; it is not a definitive methodology. The framework contains descriptions

of a core set of planning considerations that will lead to the production of computer

security acquisition specifications, as required by OMB Circular A- 130. Agencies

can use other methodologies or modify the one presented here.

B.l. PLANNING

The first phase in the procurement cycle is planning. Planning is normally divided

into General Planning and Procurement Specific Planning. General planning

involves planning on an organizational level. This section addresses the needs

determination component of general planning. Procurement specific planning

involves planning for a specific system or acquisition. In this document,

procurement specific planning is further broken down into the Requirements Analysis

and Other Planning Components.

20
B.l.a. Needs Determination

The needs determination is an initial definition of a problem that might be solved

through automation. It is also called a requirements determination. Traditional

components of the needs determination are a basic system idea, a preliminary

requirements definition, feasibility assessment, technology assessment, and some form

of approval to further investigate the problem.

A need may have been determined from strategic or tactical planning. The following

definitions are from the GSA publication Acquisition of Information Resources:

Overview Guide.

Strategic planning defines the major information resources activities and types

of information required by the organization and produces a high-level strategy

for pursuing the organization's information resource needs.

Tactical planning is the identification, scheduling, management, and control of

tasks necessary to accomplish individual activities identified in the strategic

plan.

Acquisition planning can only begin after an agency has determined that a need

exists. The needs determination phase is very high-level in terms of functionality.

No specifics of a system are defined here. The idea for a new or substantially

upgraded system and the feasibility of the idea are explored. During this early

phase of the acquisition, the definition of the security requirement should begin with

the preliminary sensitivity assessment.

Preliminary sensitivity assessment. The preliminary sensitivity assessment should

result in a brief qualitative description of the basic security needs of the system.

These should be expressed in terms of the need for integrity, availability, and

confidentiality.

This does not require an elaborate sensitivity analysis scheme, but does require an assessment of the significance of the systems. Legal implications, federal policy,

agency policy, and the functional needs of the system help determine its sensitivity.

Factors including the importance of the system to the agency mission and the

consequences of unauthorized modification, unauthorized disclosure, or unavailability

of the system or data should be considered when assessing sensitivity.

21
B.l.b. Requirements Analysis

The requirements analysis is an indepth study of the need. It draws on the work

done during the needs determination and develops it. Requirements analyses are required by FIRMR Part 201-20.102:

Agencies shall establish and document requirements for

FIP (federal information processing) resources by

conducting a requirements analysis commensurate with the

size and complexity of the need.

The following computer security components should be included in a requirements

analysis:

Analysis of integrity, availability, and confidentiality requirements;

Update sensitivity assessment;

Analysis of the level of assurance required;

Planning phase risk analysis; and

Preliminary certification/accreditation plan.

As stated above, these analyses present a conceptual framework for computer

security planning. They are intended to be used as a guide, example, or roadmap.

Other methods of computer security planning are acceptable.

While this section presents the computer security components of the requirements

analysis in sequential fashion, they can be done in a different order. For more

complex systems, they will need to be done cyclically until all of the components

work together. For smaller acquisitions, all of the components can be combined into

one analysis. Figure 5 at the end of this section shows how the computer security

components of the requirements analysis phase can interact.

Analysis of integrity, availability, and confidentiality requirements. Computer

security is defined as the process for determining, cost-justifying, and applying the

technological safeguards and managerial procedures to protect information processing

resources, including data, hardware, software, telecommunications, and related

services. In practice, the need for protection is expressed in terms of the need for

integrity, availability, and confidentiality. Integrity can be looked at from several

perspectives. From a user's or application owner's perspective, integrity is a quality

of data that is based on attributes such as accuracy and completeness. From a systems or operations perspective, integrity is the quality of data that it is only

changed in an authorized manner or that the system/software/process does what it is

supposed to do and nothing more. Like integrity, availability also has a multi-part

definition. Availability is the state when data or a system is in the place needed by

22
the user, at the time the user needs it, and in the form needed by the user. Confidentiality is the privacy, secrecy, or nondisclosure of information except to

authorized individuals.

The first step in the analysis is to determine what the protection requirements are. The analysis will be built upon the sensitivity assessment done during the needs

determination, but will be more indepth and specific.

This process should include an analysis of laws and regulations such as the Privacy

Act, the Federal Manager's Financial Integrity Act, the Computer Security Act,

OMB circulars, agency enabling acts, and other legislation and federal regulations

which define baseline security requirements. After a review of mandated

requirements, agencies should consider functional and other security requirements.

At this level, as opposed to the needs determination level, the analysis should be

system specific. The legal, functional, and other computer security requirements

should be stated in specific terms. For complex systems, this will require more than

one iteration of the requirements analysis components.

Since most systems have at least minimal integrity and availability requirements,

care should be taken to address these areas clearly. Computer security is more than

confidentiality. Even systems with no confidentiality requirement need security to

meet integrity and availability requirements.

Update Sensitivity Assessment. After completing the analysis of integrity,

availability, and confidentiality requirements, the sensitivity assessment should be

updated based on the results.

Analysis of the level of assurance required. The correct and effective use of

computer security controls is a fundamental building block of system security.

Assurance is the degree to which the purchaser of a system knows that the security

features and procedures being acquired will operate correctly and will be effective in

the purchaser's environment.

Obtaining assurance can be quite difficult because assurance can be expensive and

can be hard to quantify. This analysis needs to address how much confidence is

needed that the computer security will work correctly and effectively. The analysis

should be based on both legal and functional requirements and will be the basis for

determining how much and what kinds of assurance are required. This assurance

analysis will lead directly to the evaluation plan which will be developed in the

solicitation phase. It can also be used to help determine appropriate acceptance

criteria.

23
As with other aspects of security, it is important to remember that the goal is costeffective security, not absolute security. Absolute security is virtually impossible to

attain and can be cost prohibitive in terms of system usefulness and dollars.

There are many techniques for obtaining assurance. For a further discussion,

including a list of assurance methods, see Appendix B.

Review by Other Functional Groups. Depending on the size and scope of the

system, a team or group of participants from the functional groups described in the

beginning of this chapter may be useful. Even for small systems, it may be helpful

to get the assistance of the computer security staff. These functional groups may

have insight into the integrity, availability, confidentiality and assurance

requirements. Getting these groups involved early in the planning process is important since it may result in reduced life cycle cost because it is easier to change

requirements in the early stages.

Planning Phase Risk Analysis. The planning phase risk analysis is a critical step.

It is used to determine what types of controls will be cost-effective and forms the

basis for determining mandatory and desirable specifications. OMB Circular A- 130

requires a risk analysis prior to the approval of design specifications. In addition, a

risk analysis can provide justification in case specifications are protested.

The planning phase risk analysis will not necessarily be a large and complex

document. The analysis, like other risk analyses, should consider assets, threats to the assets, potential vulnerabilities, and what can be done to reduce vulnerabilities.

The planning phase risk analysis should take into consideration what controls already

exist and their effectiveness. The planning phase risk analysis will probably require

participation by the other functional groups.

The planning phase risk analysis will use input from the analysis of integrity,

availability, and confidentiality requirements as the basis for determining the value

of information assets and the impact of security failures. The selection of

appropriate types of safeguards should take into consideration the results of the level

of assurance analysis. The planning phase risk analysis, in turn, may point out

deficiencies in the analysis of integrity, availability and confidentiality requirements

or the level of assurance analysis by demonstrating the logical conclusion of the

analyses.

Further information on the planning phase risk analysis is contained in Appendix C.

Review by certification and/or accreditation official. OMB Circular A- 130

requires that systems be approved for processing based on the adequacy of the

safeguards. This process is referred to as both certification and accreditation in

different agencies. The approval is made by either the program manager or a

24
designated approving official. Since this official has responsibility for accepting the

risk, it is prudent to get approval of the certification and/or accreditation approach.

The certification and/or accreditation approach should address the vulnerabilities that

may exist in the system. The approving authority can advise the acquisition team if the risks appear to be acceptable. It is easier to incorporate requirement changes

during the planning stage of a system acquisition than during the solicitation, source

selection, or contract administration stages.

The acquisition team and the approving authority should also discuss what forms of assurance the approving authority needs to make a decision. This can include

system tests and other items that need to be addressed in the solicitation. Assurance

is discussed in Appendix B.

In addition, the procurement initiator and the approving authority should discuss how

changes to the system and its environment will be addressed. The possibility of a

security working group should be discussed. The group can consist of various types

of people such as application sponsors; system, security, or database administrators;

security officers or specialists; and system or application analysts. Section IV.F

presents specifications for this group.

For further information on certification and accreditation see FIPS PUB 102

Guideline for Computer Security Certification and Accreditation.

Cyclical Nature of the Process. As stated in the introduction, these requirements

analysis sub-components may need to be performed cyclically. The components

inter-relate and build on each other. Depending on the size and complexity of the

system, these components may be performed many times as ideas become refined

and focused. The flow model on the next page (fig. 5) shows how the computer

security components of the requirements analysis phase of the procurement cycle can work together.

25
FLOW MODEL FOR SECURITY

REQUIREMENTS ANALYSIS

Figure 5. Flow Model.

26
B.l.c. Other Planning Components

There are several other parts of the planning process that will incorporate computer

security in their cycles:

feasibility study,

system cost-benefit analysis,

software conversion study,

analysis of technical alternatives, and

market surveys.

The feasibility study should also look at the computer security of the system. If

security is not considered during the feasibility study, then it is possible for a computer system to be acquired for which there is no cost-effective security solution.

The cost-benefit analysis should use input from the planning phase risk analysis. If

the cost-benefit analysis does not consider security, then it is possible for it to favor a system which will later require security upgrades (which could be expensive). In

addition, it could favor a system with unnecessary exposures to traumatic failures.

The software conversion study, which examines the cost of re-establishing software

on a new hardware or software base, should include the cost of re-establishing the

desired degree of computer security on the new system and maintaining security

during the transition.

The analysis of technical alternatives should rate the alternatives against their ability

to meet all the requirements including computer security.

The market surveys, which may include Requests for Comment (RFCs) or Requests

for Information (RFIs), should include the computer security requirements.

At the end of the planning phase, the government will have determined the

requirements and the best ways to achieve them. This will include a decision on

whether a requirement can be met through acquisition or in-house development.

Many systems combine these methods. Since the planning phase looks at the whole

system, the computer security and other functional requirements should have been

adequately addressed to allow acquisition of components while maintaining system

integrity.

Many agencies have an approval process, which may include computer security, at the end of the planning phase. The approval can be used to see if the procurement

incorporates a rational risk-based approach to security planning. (It is not necessary

27
for the procurement initiator to have exactly followed the steps outlined in this

special publication; other approaches can be used.)

B.2. SOLICITATION

The second phase in the procurement cycle is the solicitation phase. This covers the

development and issuance of the request for proposals (RFP) and the receipt of

proposals.

All considerations surrounding the acquisition of the product or service must be

addressed in the solicitation. This includes the description of what is being

acquired; how it will be acquired; how it will be evaluated, tested, and accepted;

and how the contract will be administered. Although the actual evaluation of

proposals or the administration of the contract happens in later phases, these areas must be addressed now.

An RFP is designed to allow the government to make a best value decision based

on an offeror's proposal. One of the strengths of the RFP process is the flexibility

it provides the government and the offeror to negotiate a contract that best meets the

government's needs.

The government can identify needed computer security features, procedures, and

assurances in many ways. An RFP can be a flexible document which allows for

substantial creativity. Guidance on procurement alternatives should be obtained from

the agency procurement office or the contracting officer.

Because of the flexibility, it is impossible to address precise mapping of the

computer security considerations into the uniform solicitation. The procurement

initiator needs to decide how the computer security considerations will be met given

the many options an RFP provides.

This guideline explains some of the considerations for developing a statement of

work/specification and provides general guidance about evaluation, testing, and

acceptance of the computer security features. The procurement initiator must decide

how a given feature, procedure, or assurance fits in the RFP. In addition, this

guideline provides guidance about clauses.

28
B.2.a. Specifications and Work

The statement of work (SOW) or specification is based on the requirements analysis.

This section describes two types of sources for computer security specifications:

general specifications and federally mandated specifications.

Security requirements can be included in the SOW as specifications, tasks, labor,

work, level of effort, etc. The procurement initiator should concentrate on what is required and work with the contracting officer to determine how to ask for it.

General Specifications

There are many sources of general computer security specifications. NIST guidance

documents, such as this one, and guidance from other federal agencies and

commercial groups are some sources. The indexes to NIST documents are referenced below and are updated periodically. Also, DoD has extensive material

that can be used for guidance. The Trusted Computer Systems Evaluation Criteria

(TCSEC) or "Orange Book" is a DoD standard that defines many computer security

specifications. The TCSEC is a DoD standard but NOT a federal government

standard. There are also specifications in other DoD and other agency computer

security guidelines. Commercial sources and trade organizations also publish general

computer security specifications.

These computer security documents can be reviewed for applicability to the

system(s) being procured. They may represent areas that were overlooked and they can save time since they provide already prepared SOW language. Care should be

taken when selecting features, procedures, and assurances from these sources. The

items may be grouped based on interdependencies between the items. It is necessary to understand the features, procedures, assurances, and groupings before

specifying them separately.

Each specification must be justified from the requirements analysis, specifically from

the planning phase risk analysis. Safeguards recommended by a general source should be considered, but they should not be included in an RFP if the risk analysis

does not support them.

Federally Mandated Specifications

There are other sources of computer security (and nonsecurity) specifications which

are required by law to be included in the RFP. These are often referred to as directed specifications. All federal agencies must require that systems comply with

applicable FIPS PUBS and Federal Standards. Executive agencies must comply with

OMB Circular A- 130. There are also agency-specific directed specifications, which

29
are official policies issued with the concurrence of agency legal and procurement

officials.

Directed specifications must be incorporated in an RFP if the system being acquired

matches the criteria in the directed specification. It is very important to be aware of

directed specifications. If specifications in an RFP conflict with directed

specifications, a waiver must be obtained.

The following publications contain lists of standards including FIPS PUBS and

Federal Standards:

NIST Publications List 58 - Federal Information Processing Standards

Publications (FIPS PUBS) Index

NIST Publication List 88 - Computer Systems Publications

NIST Publications List 91 - Computer Security Publications

GSA Handbook "Federal ADP and Telecommunications Standards Index"

Ordering information for NIST publications is printed on the inside back cover of

this document. The GSA Handbook is available from the Government Printing

Office.

Another source for directed specifications is the Model Framework for Management

Control Over Automated Information Systems published jointly by the President's

Council on Management Improvement and President's Council on Integrity and

Efficiency. This document provides guidance on requirements for control imposed

by the Federal Manager's Financial Integrity Act of 1982, the Privacy Act of 1974,

and OMB Circulars A-123, A-127, and A-130. The Framework states, "...federal

managers are expected to: Understand the 55 control requirements identified in the report; and

Implement a program that demonstrates compliance with the requirements."

It is incumbent on the procurement initiator to know what federal standards apply to

the system(s) being procured. Many people erroneously feel that this is the

responsibility of the contracting officer. These are technical issues and are, therefore, the responsibility of the procurement initiator.

B.2.b. Evaluation

Evaluation is the process of determining if an offer meets the minimum requirements

described in the RFP and an assessment of the offeror's ability to successfully

accomplish the prospective contract. This involves a technical analysis of the merits

of a proposal. As part of the solicitation phase, the procurement initiator, working

with the contracting officer, develops an evaluation plan to determine the basis for

30
the evaluation and how it will be conducted. The evaluation itself is performed

during the source selection phase of the procurement.

Developing an Evaluation Plan.

When evaluating computer security features, it can be difficult to assess if the offer

meets the minimum requirements or can successfully accomplish the prospective

contract. Therefore, offerors should have to provide assurance to the government

that hardware and software claims regarding computer security features are true and

that the offeror can provide the proposed services. Since computer security, like

other parts of computer systems, is a complex and important subject, the offeror's

assertions may not provide sufficient assurance. Appendix B further discusses assurance and presents ideas for how the government can obtain it. In addition,

section IV.D provides descriptions of documentation that can be used for assurance

in the evaluation phase, such as the offeror's strategy for security.

How assurances are provided may, in fact, determine the ability of the government

to adequately assess them. Security personnel need to be sure they are asking for

the information they really need. If, after award, the government determines that

more assurance is required, the government may be liable for additional costs.

The determination of how the offerors will be required to provide assurance should

be considered when developing the evaluation plan. This plan will be used to help

develop sections of the RFP which provide instructions to the offerors and

information about how the proposals will be evaluated and how source selection will

be performed.

As part of this process, a determination of security acceptance testing should be

made. It may be important to coordinate evaluation and acceptance to effectively

manage the security review and testing of proposals and deliverables.

Items to Consider in the Evaluation Plan.

The remainder of this section presents ideas to assist with the development of the

computer security aspects of the evaluation plan. One aspect of the evaluation plan

is selecting evaluation team members. Section III.B.3, Source Selection, discusses

some of the roles and duties of the evaluation team.

When the evaluation plan is developed, keep in mind that alternatives may conflict

with each other. For example, features which provide computer security can conflict

with those that provide ease of use. The government must make it clear how

offerors should propose different configurations and present conflicting options and

31
trade-offs. However, care should be taken to keep proposal size manageable to

facilitate review and to keep proposal preparation costs down.

When computer security is important in the acquisition, it must be addressed in the

evaluation criteria so that offerors will know that it is important to the government.

Offerors look at the RFP to determine what the government considers most

important.

Testing is one method of determining if the proposed system or product can meet

the computer security requirements. Depending on the nature of the system, this can

be part of the proposal evaluation, in the form of live test demonstrations or benchmarks, or it can be part of post-award acceptance testing. During the

evaluation process there are different times when the testing can occur. There are

cost, technical, and procurement integrity considerations for deciding when testing is done. In general, expensive tests should be kept to a minimum. This will help

control offeror proposal preparation costs. Not only do expensive proposals limit

competition, but the costs are ultimately passed to the government in higher contract

costs. Guidance on testing alternatives should be obtained from the contracting

officer.

Note: Be sure the computer system testing, especially performance testing, is done

with the computer security features enabled.

Warning: The more the procurement initiator knows about the market place, the

easier it is to develop an evaluation plan. Proposals cannot be used for market

research. The evaluation plan virtually cannot be changed after the receipt of

proposals. Additional knowledge learned by reading proposals cannot be used to

modify the evaluation plan. It is worth the time to research what kind of

alternatives could be offered so a scheme that reflects the true priorities of the

government can be developed.

B.2.c. Special Contract Requirements

There are elements in an RFP that are computer security-related but are not

contained in the statement of work or the evaluation criteria. These elements

usually address rights, responsibilities, and remedies assigned to the parties of the

contract. Many times such obligations survive the actual performance period of the

contract. Therefore, such elements are best addressed through specific contract

clauses or requirements. The nondisclosure of automated information learned during

the course of the contract is one example.

32
Chapter four addresses clauses as well as statement of work items. The

procurement initiator must coordinate with the contracting officer about clauses to be

added to an RFP.

B.3. SOURCE SELECTION

Source selection is the determination of the successful offeror. The source selection

phase is based on the work done in the planning and solicitation phases. This phase

involves actually evaluating the proposals and making best value decisions based on

the evaluation criteria and other factors stated in the RFP. Computer security

considerations incorporated during the planning and solicitation phases will be a part

of the evaluation and source selection.

An individual with extensive computer security expertise should be part of the

evaluation team. This expert should be available to review the original proposals as well as clarifications, discussion points, and best and final offers (BAFOs). A good

review team is essential to the success of a procurement.

B.4. ADMINISTRATION AND CLOSEOUT

The final phase in the procurement life cycle is administration and closeout.

Computer security issues for administration and closeout should have been addressed

when developing the solicitation. Two important computer security functions during

this phase are acceptance and monitoring contractor performance.

Acceptance. Acceptance refers to the government's decision to accept, and

therefore, pay for a deliverable. The government should be careful in accepting

deliverables. Testing by the government or an independent validation and

verification (IV&V) contractor to determine that the system does meet specifications can be very useful. This should include testing the security of the system.

Note: Acceptance and approval to operate (certification or accreditation) are related,

but different concepts. The government normally accepts a deliverable that meets

the specifications in the contract. The approval to operate is a separate decision

made based on the risks and advantages of the system. It is incorrect to have the

approval to operate as one of the acceptance criteria.

Monitoring. In general, the government should plan to review contractor

performance to ensure that security has not degraded and that changes in the

environment and system that result in new threats and vulnerabilities are recognized

and appropriate safeguards put in place. For more complex contracts including more

33
than just purchase of hardware, a security working group is an effective way to

monitor security. Section IV.F provides features, procedures, and assurances related

to contract administration and closeout.

After award, the government's requirements should not change. If they do, there are mechanisms to modify the contract to accommodate some changes. However, these

modifications can be quite costly. In addition, some changes may require separate

procurements. As noted in the introduction to this document, new security controls

that are retrofitted to a system may not be as effective as controls designed into the

system.

34
COMPUTER SECURITY IN

PLANNING

NEEDS REQUIREMENTS OTHER PLANNING

DETERMINATION ANALYSIS COMPONENTS

STRATFGI C/TAfTI CAI REQUIREMENTS ri_ . _. m FEA5IBLITY STUDY

Dl iMMIMR ANALYSIS

COST-BENEFIT ANALYSIS

RASIf SYSTFM IDFA

I—

zz. SOFTWARE CONVERSION

UJ PRELIMINARY REQUIREMENTS STUDY

Y.

L±J DFFINITION

t_I_ ANALYSIS OF TECHNICAL ZD

(_J UJ

1 PRELIMINARY FEASIBILITY ALTERNATIVES

o (_) ASSESSMENT

cr >-

CL U MARKET SURVEYS

PRELIMINARY TECHNOLOGY

AO Jt J Jl 1 C IN 1

PRELIMINARY SENSITIVITY INTFGRITY AVAII ARII ITY

CO

ASSESSMENT fOMFinFMTI Al ITY ANAIY^IS

z

UPDATE SENSITIVITY

h-

<

ASSFSSMFMT

>- cr h- UJ

^—

\

LEVEL OF ASSURANCE

cc

£_J ANALYSIS

ZD CO

u zz. LU o PLANNING PHASE RISK

CO CJ ANALYSIS

REVIEW BY OTHER FUNCTIONAL

GROUPS

REVIEW BY CERTIFICATION/

ALLKtU 1 IAI lUINUrMLIAL

1 1 1 u III.B.l.a III.B.l.b III. B.I.

c

Z zz o UJ

f—

cr

LJ UJu_ UJ UJ

CO cr

Figure 6. Computer Security in the Procurement Cycle.

35
THE PROCUREMENT CYCLE

SOLICITATION

SOURCE

SELECTION

AnkJllMICTDATinM AUMIInIo 1 HA 1 IUIm

& CLOSEOUT

DEVELOP STATEMENT OF WORK EVALUATE

PROPOSALS

INSPECTION & ACCEPTANCE

DEVELOP EVALUATION PLAN COTR RESPONSIBILITIES

REVIEW SOLICITATION

DEVELOP SECURITY ASPECT OF

STATEMENT OF WORK

SPECIFICATIONS, FEATURES,

ASSURANCES, TASKS

PARTICPATE IN TECHNICAL

EVALUATION

EVALUATE SECURITY

INSPECTION & ACCEPTANCE

OF SECURITY OF SYSTEM

SECURITY WORKING GROUP

DETERMINE SECURITY EVALUATION

& ACCEPTANCE CRITERIA

ASPECTS OF

PROPOSALS

PROTECT GOVT

RESOURCES/ASSETS

REVIEW SOI IflTATION FOR

SECURITY CONCERNS

III.B.2 III.B.3 III.B.4

(entire)

This figure is intended as a guideline. These analyses/components

may have different names at various agencies

35a
/

CHAPTER IV

SPECIFICATIONS, CLAUSES, AND TASKS

This chapter provides specifications, tasks, and clauses that can be used in RFPs to acquire computer security features, procedures, and assurances. None of the

specifications, tasks, or clauses are mandatory. They are intended as a source of

general specifications, as defined in section III.B.2.a. They are written for different

types of acquisitions including purchase of off-the-shelf products, purchase of

integrated systems, development of applications, and other computer-related services.

The specifications, tasks, and clauses are divided into ten categories. Within each

category there may be specifications, tasks, and/or clauses as well as explanations,

considerations, and/or prescriptions about their use. The specifications, tasks, and

clauses are printed in courier typeface. Explanations, considerations, and

prescriptions are in regular type face. None of the specifications, tasks, or clauses

should be used blindly. Each of them should be tailored to meet individual

circumstances. The categories are:

A. General Computer Security

B. Control of Hardware and Software

C. Control of Information/Data

D. Documentation

E. Legal Issues

F. Contract Administration, End of Task, Closeout

G. Computer Security Training

H. Personnel Security

I. Physical Security

J. Computer Security Features in Systems

A word of caution on the use of subcontractors: Ensure applicable computer

security requirements and/or certifications placed on prime contractors are also

reflected in subcontracts. This is called "flowdown."

37
The categories above do not address tasking language for specific security services

such as having a risk analysis performed or having contractors prepare security

planning documents. Tasking language for these types of services are provided in

another NIST report, Sample Statements of Work for Federal Computer Security

Services.

38
A. General Computer Security

In keeping with OMB Circular A- 130, Appendix III, security responsibility must be

assigned. The responsibility must rest with a government employee. This item

should be included to clarify responsibility. If the contract calls for computer

security administration, management, or support, the delineation of responsibilities

should be clear, with the government person retaining ultimate responsibility.

The person responsible for computer security is .

The following can be used to show the relationship between agency ownership of

federal information processing (FIP) resources and contractor use. These clauses

help establish clear lines of authority and responsibility.

The government authorizes the use of agency computer resources (list

specific resources if appropriate) for contractor performance of the

effort required by the statement of work of this contract.

The contractor shall comply with the requirements of the agency

computer security program as defined by (insert agency handbook,

directives, manuals, etc.)

39
B. Control of Hardware and Software

The government should consider who can introduce hardware and software onto the

system and under what circumstances.

Introduction and Change of Software - In order to reduce the chance of viruses and

other forms of malicious code, of illegal use of licensed software, and of software

that may open security vulnerabilities (such as operating system utilities or untested

software updates), consider restricting contractors by using the following types of

specifications and tasks. These specifications and tasks could be used when the

contractor is providing a service such as running or maintaining a government

computer system.

Only licensed software and in-house developed code (including

government and contractor developed) shall be used on (system

name(s)) . No public domain, shareware, or bulletin board software

shall be installed unless prior written approval is obtained from

the contracting officer or COTR.

The following specification is fairly restrictive. The alternatives which follow can be used to modify the specification.

The only hardware and software packages that shall be used on

(system name ( s )) is (listed here or specify section). All

additional hardware and software packages proposed for use,

including upgrades, must be approved in advance and in writing by

the contracting officer or COTR.

Alternatives

The contractor shall provide a list of software and hardware

changes working days in advance of installing (or

other time or performance period)

The contractor shall provide an impact analysis for proposed

hardware and software changes that includes an assessment of

possible new security vulnerabilities (include other assessment

items required) working days in advance of installing.

The contractor shall provide proposed hardware and software for

testing working days in advance of loading.

The contractor shall provide proof of license for new software.

The contractor shall maintain a list of hardware, firmware, and

software changes throughout the contract. The contractor shall

40
provide this list to the government (specify time frame and/or

at the end of the contract)

If the contractor is using their own software, then the following specification can be

used to help protect the government from buying products developed with stolen

software.

The contractor shall provide proof of license for all software used

to perform under this contract.

The following clauses are reprinted from FIRMR Section 201-39.5202-5, Privacy or Security Safeguards. FIRMR Section 201-39.1001-3 prescribes that these clauses, or

variations of them, be used in solicitations and contracts requiring security of FIP

resources or for the design, development, or operation of a system or records using

commercial FIP services or support services. Clause (a), which addresses ownership

of and rights to developed software, should be coordinated with the contracting

officer or legal counsel.

(a) The details of any safeguards that the contractor may design or

develop under this contract are the property of the government and

shall not be published or disclosed in any manner without the

contracting officer's express written consent.

(b) The details of any safeguards that may be revealed to the

Contractor by the government in the course of performance under this

contract shall not be published or disclosed in any manner without

the contracting officer's express written consent.

(c) The government shall be afforded full, free, and uninhibited

access to all facilities, installation, technical capabilities,

operations, documentation, records, and data bases for the purpose

of carrying out a program of inspection to ensure continued efficacy

and efficiency of safeguards against threats and hazards to data

security, integrity, and confidentiality.

(d) If new or unanticipated threats or hazards are discovered by

either the government or the contractor, or if existing safeguards

have ceased to function, the discoverer shall immediately bring the

situation to the attention of the other party. Mutual agreement

shall then be reached on changes or corrections to existing

safeguards or institution of new safeguards, with final

determination of appropriateness being made by the government. The

government's liability is limited to an equitable adjustment of cost

for such changes or corrections, and the government shall not be

liable for claims of loss of business, damage to reputation, or

damages of any other kind arising from discovery of new or

unanticipated threats or hazards, or any public or private

disclosure thereof.

41
One option to modify these clauses is to add a task related to clause (d):

The contractor shall provide an analysis of the new threat, hazard,

or vulnerability and recommend possible fixes or safeguards.

The following two clauses address other issues in the use of government hardware

and software by a contractor providing services. The government should include all restrictions such as single site licensing, proper use to maintain warranties,

proprietary code, or special considerations.

Under no circumstances is a contractor permitted to make any use of

agency computer equipment or supplies for purposes other than

performance on this contract.

The following items of government furnished equipment or software

have the following licensing or use restrictions: (provide list)

The special needs of personal computers should be addressed. There are many PC

security options such as PC security hardware and software, locks, removable hard

drives, and anti-virus software. Consider if these are needed when PCs are acquired

or if contractors will be using PCs. Remember that a PC used as a terminal is still a computer.

The contractor shall not allow employees to use files for logging

onto systems that contain the employee's passwords.

Pre-logon warning messages can deter unauthorized use, increase computer security

awareness, and provide a legal basis for prosecuting unauthorized access. Consider

having an installation, support, or integration contractor configure multi-user systems

with a warning message. Warning messages can also be used on contractor systems

processing federal information.

The system (s) shall be delivered/installed with the following

message appearing before logon:

(or)

Contractor multi-user systems used to process data under this

contract shall use the following pre-logon warning message:

42
WARNING WARNING WARNING ********************************************************

THIS COMPUTER IS OPERATED BY/FOR THE U.S. GOVERNMENT. UNAUTHORIZED

ACCESS TO AND/OR USE OF THIS COMPUTER SYSTEM IS A VIOLATION OF LAW

AND PUNISHABLE UNDER THE PROVISIONS OF 18 USC 1029, 18 USC 1030, AND

OTHER APPLICABLE STATUTES.

****************************************1r ***.)r

.k ***i. ic ±i. icie ic * ic irir 1.* i

. WARNING WARNING WARNING

Having the contractor provide contingency, continuity of operations, and disaster

recovery plans for government systems or for their own systems that process

government data is another important issue. The following addresses continuity of

operations planning for a mission-essential network, but can be tailored for other

types of systems. To use this clause, the offerors must have sufficient information

to be able to postulate the types of emergencies that could occur. It may be

necessary to provide additional detailed specifications to give offerors and evaluators

enough information to prepare/review cost estimates and to make objective

evaluations.

Add to Section L:

As part of the proposal, the offeror shall submit a preliminary

continuity of operations plan to address the planned reaction to

threatened or actual emergencies. Provisions for testing the plan,

at the option of the agency, must be included in the proposal.

The offeror shall describe how proposed architecture, technical

capabilities and organization will protect the system during

emergency situations. The plan should state what priority the

agency will have in terms of services, replacement hardware, etc.

Examples of how these resources will be brought to bear during an

emergency are required.

The offeror shall describe external emergency management interface

arrangements that will be used with subcontractors if necessary.

The agency is concerned that service may be degraded in a network

environment in which switching systems and transmission channel are

shared with others. If the offeror proposes such a shared

environment, the offeror must address the following issues:

protection of critical agency users from access blocking;

protection of network access ports from saturation caused by

other traffic that may be using the network access ports; and

provision of low delay, low blocking access to all necessary

intercity routes and access facilities for critical users

during periods of overload.

43
Add to Section C:

After contract award, the contractor shall deliver a draft

continuity of operations plan for the system being acquired for

agency approval within ninety days of receiving the agency approval

and/or guidance on the preliminary plan. The final continuity of

operations plan shall be delivered ninety days after receiving

agency approval and/or guidance on the draft plan. The plan shall

be periodically reviewed and updated annually by the Contractor to

ensure the accuracy and timeliness of the contents. Recommended

updates and revision based on this review shall be submitted to the

agency for approval working days prior to incorporation in the

plan

Summary

Preliminary plan submitted with proposal;

Draft plan submitted working days after agency

comment on preliminary plan; and

Final plan submitted working days after agency

comment on draft plan.

The continuity of operations plan shall detail the taking of

appropriate and timely action to protect system assets from damage

or misappropriation in the event of the threat of a disaster or

emergency. The emphasis shall be on avoiding or mitigating the

damage caused by such things as fire, flood, or terrorist activity

(modify to include threats to the system) . The plan shall, at a

minimum:

Include a risk assessment;

Identify essential functions or critical processes, components,

and the relationship of critical workload to variables such as

time to recovery;

Identify activities that can be temporarily suspended;

Identify alternate procedures; and

Identity action (s) to be taken to mitigate threats.

The continuity of operations plan shall detail the taking of

appropriate and timely action to return assets to use after damage,

destruction, alteration or misappropriation. The system recovery

portion of the plan shall include at a minimum:

The basic strategy for recovery;

Specifications for restoration procedures by component and

subsystem priority; and

Specific responsibilities for emergency response.

The continuity of operations plan shall state how the plan shall be

tested and how often the tests shall be done. Annual testing is

44
required as a minimum and some tests should be done without advance

notice

As part of continuity of operations/contingency planning, consider how long the

system can be down.

In the event the system or any component is rendered permanently

inoperative, the contractor shall deliver a replacement within

working days from the date of request.

In the event the system or any component is unavailable for use due

to maintenance or repair or other reasons for a period of more than

hours (or days) , or in the event that it is reasonably

anticipated that maintenance will exceed hours, the contractor

shall make a loaner or replacement available within hours (or

days)

45
C. Control of Information/Data

Contractors may have to work with information or data that the agency has

designated as nondisclosable. Clauses should be used to prevent the contractor from

disclosing the information during the course of the contract and after it has

terminated. It is important to work with the contracting officer to ensure that

nondisclosure is adequately addressed for both situations.

Any (list type of or all) information made available in any format

shall be used only for the purpose of carrying out the provisions of

this contract. Information contained in such material shall not be

divulged or made known in any manner to any person except as may be

necessary in the performance of this contract. Disclosure to anyone

other than an authorized officer or employee of the contractor shall

require written approval of the contracting officer (or contracting

officer's technical representat ive/COTR)

Any (list type of) information shall be accounted for upon receipt

and properly stored before, during and after processing. In

addition, all related output shall be given the same level of

protection as required for the source material.

If it is necessary to disclose (type of) information to perform

under the contract, the contractor shall request written

authorization from the contracting officer (or COTR) to make such

necessary disclosure.

(1) Except as provided elsewhere in this contract, the

contractor shall not disclose (type of information) except to

the individual specified in this contract.

(2) Only those disclosures specifically authorized in writing

by the contracting officer (or COTR) may be made, and only when

it is clearly shown by the contractor that such disclosures are

essential to successfully perform under this contract.

(3) Should the contractor or one of his/her employees make any

unauthorized disclosure ( s ) of confidential information, the

terms of the Default clause (FAR 52.249-8), incorporated herein

by reference, may be invoked, and the contractor will be

considered to be in breach of this contract.

If nondisclosable information is released to prospective offerors in order for them to prepare proposals, the following clause can be used during the release of

information.

46
I hereby certify that I will not disclose (type of information)

unless authorized in writing by the contracting officer (or COTR)

I agree that, whether or not a contract is awarded to me, I will

keep all information confidential.

The following item is to prevent nondisclosable information from leaving the

agency's control through such means as being on a disk drive sent out for

maintenance.

The contractor shall ensure that (list type of) information shall

not be released outside the control of the agency (or specific

agency office) , including release for maintenance or replacement

purposes, without the written consent of the contracting officer or

COTR

47
D. Security Documentation

Security documentation provides instruction about the use of the system security, assurance that the security requirement has been understood, and supports a demonstration of meeting the requirement. The items below are divided into

proposal and deliverable documentation. In general, documentation that shows that a requirement has been understood will be received as part of the proposal and will be

used to evaluate the offeror. Instructional documentation will, in general, be

received as a deliverable after contract award. Documentation, such as test documentation, that demonstrates that the contractor has successfully met the security

requirement will normally be received as a deliverable after contract award.

Depending on the nature of what is being acquired, these types of documentation

can be mixed. For instance, an approach, abstract, or outline of a Security Features

User's Guide can be included in the proposal with the final version as a deliverable.

In the proposal phase, the document would be used to evaluate the offeror's

understanding of the security requirement and their ability to meet the requirement.

As a deliverable, this would become instructional documentation. Be sure documentation requested with the proposal is used for evaluation of the offer and

does not constitute having the offeror prepare deliverables before award.

Depending on what is being acquired, be sure to get system level documentation,

not just component documentation. For any type of documentation at the system

level, the contractor should describe the system security requirement and how it has

been implemented. The operating system documentation plus the security system

documentation plus application documentation does not equal system documentation.

System security documentation includes interrelationships among applications and

with the operating system and utilities in its environment. Component

documentation will generally be off-the-shelf, whereas system documentation will

generally be developed by the contractor.

It may be necessary to provide additional detailed specifications, including content

and delivery schedule, to give offerors and evaluators enough information to

prepare/review cost estimates and to make objective evaluations.

PROPOSAL DOCUMENTATION

Offeror's strategy for security. This should be commensurate with the size and

complexity of the system. All systems acquisitions should request some form of

offeror security strategy. In this strategy, the offeror should state how the product

or service will meet the security needs of the government. Offerors of off-the-shelf

products should match the features of the packages to government specifications and

48
address assurance. For complex system development efforts, this could include a plan for incorporating and assuring security throughout the development. An

example of a clause requesting such a plan follows.

The offeror shall provide a plan that describes its automated

information security program. The plan shall address the security

measures and program safeguards which will be provided to ensure

that all information systems and resources acquired and utilized in

the performance of the contract by contractor and subcontractor

personnel

(1) Operate effectively and accurately;

(2) Are protected from unauthorized alteration, disclosure,

or misuse of information processed, stored, or

transmitted;

(3) Can maintain the continuity of automated information

support for agency missions, programs, and function;

(4) Incorporate management, general, and application controls

sufficient to provide cost-effective assurance of the

system's integrity and accuracy, and

(5) Have appropriate technical, personnel, administrative,

environmental, and access safeguards.

This plan will be included in any resulting contract for contractor

compliance

Offeror's internal security policy and plan. Procurements that include contract

services can ask for this type of assurance document. Depending on the scope of

the acquisition, this may include copies of the offeror's applicable computer security,

personnel security, and physical security policies.

DELIVERABLE DOCUMENTATION

Security Features User's Guide. A description of the protection mechanisms

provided by the system, guidelines on their use, and how they interact with one

another. If a system is being procured, be sure to get system level documentation,

as well as product documentation.

System Administrator/Facility Manual. A manual addressed to the system

administrator that presents cautions about functions and privileges that should be

controlled when running the system or facility in a secure manner. The procedures

for examining and maintaining security features requested (such as audit record

structures) should also be requested. The manual should describe the operator and

administrator functions related to security, to include changing the security

characteristics of a user. It should provide guidelines on the consistent and effective use of the protection features of the system, how they interact, warning, and

49
privileges that need to be controlled in order to operate the system or facility in a

secure manner. If a system is being procured, be sure to get system level

documentation, as well as product documentation.

Test documentation. A report that describes the test plan, test procedures that

show how the security mechanisms were tested and results of the security

mechanisms' functional testing.

Design documentation. A report that provides a description of the manufacturer's

or developer's philosophy of protection and an explanation of how this philosophy is translated in the system. This report can be the post-contract award counterpart of

the offeror's strategy for security; it describes how the strategy was implemented.

This can also include an informal or formal description of a security policy model

and an explanation of how the system enforces the security policy. For systems

requiring very high security assurance, formal description languages and

mathematical modeling may also be included.

Additional information on documentation for automated systems is available from the

following FIPS PUBs:

FIPS 38 Guidelines for Documentation of Computer Programs and

Automated Data Systems

FIPS 64 Guidelines for Documentation of Computer Programs and

Automated Systems for the Initiation Phase

50
E. Legal Issues

The contracting officer and the legal department need to be consulted about legal

issues. This section addresses some issues that the procurement initiator may want

to discuss with agency procurement and legal staff.

It is possible for computer products to cause security violations even if the products

are functioning correctly. These violations could be caused by the product

containing malicious code (i.e., virus or trojan horse), making operating system calls

that bypass system controls, or containing undocumented backdoors that bypass

security. Many manufacturers include backdoors so they can assist customers.

The FAR contains general clauses which define the respective responsibilities and

allocate risks among the parties to a government contract. However, additional

clauses may be needed to fully address specific computer security requirements.

Such clauses, for example, may address guarantees, warranties, or liquidated

damages. The specific wording of such clauses may vary from one solicitation to

another because they are a function of the particular need for data integrity,

confidentiality or availability and the nature of the system being protected.

Agencies may wish to consider the use of warranties, liquidated damages, and other

clauses establishing the contractor's computer security-related responsibilities in

contracts. Such clauses, when properly crafted, will provide incentive to the

contractor to assure that its products and services meet the security requirements of

the contract. Such clauses, when poorly drafted or overly broad, can unnecessarily

increase contract costs, limit competition, complicate contract administration and

increase litigation risk. These clauses must be prepared in conjunction with existing

FAR clauses.

Warranties provide a means to require the contractor to fix products after they have

been accepted. A warranty is an agreement by the contractor that it will be liable

for meeting the contract specifications for a stated period of time after acceptance.

(See FAR 46.7 and 52.246-17 through -20.)

Liquidated damages provide a means for the contractor to compensate the

government for losses that result from contract delays or other problems. The

purpose of liquidated damages clauses and other clauses fixing contractor's

performance responsibilities in the computer security area is to provide incentive for

the contractor to make sure that the product only does what it is intended to do and

nothing more. For example, the product should be free from malicious code. This

is done by having the contractor pay for damages that result from poor security.

Since the goal is to acquire secure systems, the extent of the liquidated damages

51
clause (or other such clause) should be commensurate with the anticipated risks and

damage to the government. A specific maximum dollar value can be placed on the

damages or other means can be used to limit the contractor's liability.

Note: These are not penalties. If a security violation occurs, but does not result in

any loss, the contractor is not responsible for any liability or liquidated damage.

The following are examples of integrity statements which may be modified to form

a warranty, guarantee, or liquidated damage clause. The examples are not intended

to be used together and should be modified for the operating environment. There

are no examples of customized enforcement clauses (the specific warranty, guarantee,

or liquidated damage) because they must be developed with the contracting officer

and legal counsel. FAR 52.246-17 through -20 contain FAR standard warranties.

1. The subject product performs in accordance with all

specifications, certifications, and representations reflected

in the documentation provided in Addendum 1 except as reflected

below:

2. The installation instructions provided with the subject product

if properly followed shall result in the creation and

modification of only those objects listed below:

3. The subject product (hardware or software) shall not interact

with any other component (hardware, software, or firmware) of

the system onto which it is being installed to perform any

function not described in the documentation listed below:

4. The instructions provided for removing the subject product from

any system onto which it has been properly installed, shall, if

properly followed, release back to the system every object used

to store the subject product on the system.

52
5. Other than the exceptions listed below, the subject product

contains no undocumented functions and no undocumented methods

for gaining access to this software or to the computer system

on which it is installed. This includes, but is not limited

to, master access keys, back doors, or trapdoors.

6. The subject product does not interfere or bypass the system

security software [insert name(s) of security software]. The

program code only performs request validation checking and

enforces the action that the system security software indicates

should be taken. This processing is done for all users. Any

exceptions are listed below.

Government patents and ownership of developed software and systems are another

important considerations that should be discussed with the contracting officer and

legal staff.

53
F. Administration, End of Task, Closeout

One issue for contract closeout is the return or destruction of government

data/information. Since information can be easily copied, the return of originals

does not fully address the destruction of the information. This issue only needs to

be addressed when the government is having information processed on a contractor

facility or computer. Be sure that official agency records or information is not

destroyed before a copy of the information has been received by the agency (if

needed).

The contractor certifies that the data processed during the

performance of this contract shall be purged from all data storage

components of its computer facility, and no output will be retained

by the contractor after such time as the contract is completed. If

immediate purging of all data storage components is not possible,

the contractor certifies that any agency data remaining in any

storage component will be safeguarded to prevent unauthorized

disclosures. (Insert schedule.)

Government furnished equipment (GFE) including hardware and software should be

returned in accordance with normal procedures. Special computer security

considerations include the return of the GFE in usable condition. This is especially

important if a system is going to continue operation under the government's or another contractor's control. The computer security can be transferred by having

passwords reset by the government or by having the contractor turn in the

passwords. The delineation of security responsibilities during transition should be

addressed. No specific language is provided because of the diversity and

individuality of systems.

Returned software shall be certified to be in its original form.

Another item to be considered is computer accounts on government-owned systems.

Accounts no longer needed by the contractor should be terminated to protect

government resources, i.e., computer time, and to prevent malicious activity by

unauthorized users.

When an employee no longer requires access to the system (if the

employee leaves the company or the contract), the contractor shall

notify the COTR within working days. At contract

completion or termination, the contractor shall provide a status

list of all users and note if any users still require access to the

system to perform work under another contract. Any group accounts

or other means of gaining access to the system shall be listed also.

This includes maintenance accounts and security bypasses.

54
If a user is fired or leaves the contract or company under adverse

conditions, the contractor shall notify the COTR before the employee

is removed. If the removal is unplanned, the contractor shall

notify the COTR immediately after dismissing the employee. This

will allow the government to terminate his/her access.

When an employee leaves a contract and at contract closeout, it is important to dispose of computer files as well as accounts. Often only the person who

created/used the files has sufficient knowledge to dispose of them. If the contractor

will be handling official agency records, be sure disposition is made in accordance

with agency records management instructions.

When an employee leaves the contract, the contractor project manager

shall ensure that all files are disposed of by transfer to another

user, archive, destruction, etc. The contractor project manager

shall report (or certify) disposition in (time frame such as in a monthly report or within weeks of the employee leaving.)

For complex contracts that include the development, implementation, or operation of

a computer facility or application, a security working group can be used effectively

to help maintain computer security. The group can be composed of a combination

of government and contractor personnel. Depending on the operational environment,

the group can be used for:

information exchange;

configuration management;

certification and accreditation issues;

analyzing security requirements;

identifying new threats and vulnerabilities;

identifying changes to the system that impact security;

recommending solutions to security problems as they occur; and

making recommendations based on tradeoffs between security and other

functional requirements.

The following examples define a security working group used to support an

operational system.

The contractor shall provide (number and type of) personnel for a security control /review group. This group will address security

problems, help provide for the maintenance of accreditation or

certification under the control of (government person responsible

for computer security of system) , report security problems, and make

security recommendations.

The contractor can be responsible for the administration and support of the group.

55
The contractor shall schedule meetings monthly (or other time

frame), arrange for (or provide) a room, and take minutes. The

minutes will be submitted to the COTR/GTR within one calendar week

after the meeting. The meetings shall commence one month (or other

time frame) after contract award and continue throughout the period

of performance (or other ending time)

56
G. Computer Security Training and Awareness

An important goal of the Computer Security Act is to have all personnel involved in

the management, use, and operation of federal systems trained in computer security awareness and accepted computer security practices. OMB Circular A- 130,

Appendix HI, specifically requires that contractor personnel involved in the

management, operation, programming, maintenance, or use of federal systems be

aware of their security responsibilities and how to fulfill them.

The following can be used in the cases where the agency determines that NIST

Special Publication 500-172 "Computer Security Training Guidelines" adequately

addresses the security training requirement for the contractor. This can be tailored

to include specific additional skills, training levels, or audience categories depending

on the requirements of the agency. A time frame should be specified for when the

contractor personnel must have received the training. The development of training

certifications should be discussed with the contracting officer.

The contractor shall, at a minimum, certify that all contractor

personnel involved in the management, use, and operation of (name

of) system (s) who perform work under the subject effort shall have

received training appropriate to their assignment as defined in NIST

Special Publication 500-172 "Computer Security Training Guidelines."

Each individual (or category of contractor personnel) proposed for

the effort shall be identified with appropriate audience

category(s), as defined in NIST Special Publication 500-172, pages

3-4. The contractor shall certify each as having received computer

security training appropriate to their categories, as denoted in the

training matrix on page 6 of 500-172 and described in pages 8-27.

Additional /refresher training shall be performed (time

period) . Certification of this training shall be provided to the

contracting officer no later than calendar days after the

training has occurred.

The following are examples of tailoring the training specification.

In addition, all contractor personnel involved in the administration

of the access control package shall have received training on the

package equivalent to hours of classroom instruction or

hours of job experience using the package.

The contractor system security personnel shall have received

training in the operations of the system that includes a systemic

overview, the security features, known vulnerabilities and threats,

and security evaluation methodologies.

57
The following can be used when the acquisition agency has specific training

minimums that are available to the prospective offerors. The second paragraph may

be added as an Instruction to Offerors.

The contractor shall, at a minimum, certify that any personnel who

perform work under the subject effort shall have received security

awareness and skills training that is equivalent to that received by

government personnel at (fill in location).

It is the responsibility of the prospective offeror to obtain the

agency guidelines for this training prior to the submission of a proposal under this solicitation at (fill in address and point of

contact) . (Alternate: The agency guidelines can be included as an

attachment to the RFP .

58
H. Personnel Security

Requiring vetting, or personnel screening, of contractor or subcontractor employees

as a condition for access to government resources is a recommended safeguard. The

type of access can be physical or computer systems access. The level of vetting

should be based on an assessment of risk, cost, benefit, and feasibility. Vetting

includes a range of implementations from minimal checks to full background

investigations. The extent of screening is dependent on the sensitivity of the system

or data and the implementation of other administrative, technical, and physical

safeguards.

Be sure to include in the contract:

what types of investigations are required for what types of access; who will review the investigation to determine access privileges;

who is paying for the investigations;

whether the investigations must be reviewed before access is granted;

when names and supporting information must be submitted;

what other types of clearances (from other government agencies) can be

substituted; and

how investigations or results will be reported on or certified to the contracting

officer.

Different vetting could also be required for different types or levels of access. There are many kinds of investigations. OPM Federal Personnel Manual Chapter

736 Subchapter 3 describes some investigations as they pertain to government

investigations. The list below includes those and other forms of investigations:

Review of the employment forms completed by the individual;

Personal reference check;

Credit check;

Verification of employment for the last 2 years prior to current employment;

Verification of education (high school or beyond) within the last 5 years that

resulted in the awarding of a degree;

Local police check in present county and state; National criminal check by private agency;

National Agency Check (NAC);

National Agency Check and Inquiries (NACI);

Minimum Background Investigation (MBI);

Limited Background Investigation (LBI);

Background Investigation (BI); and

59
Special Background Investigation (SBI) that includes verification of all previous places of employment and residence for a several year period (e.g.,

15 years).

Access to the government's resources is a privilege and should be revoked if an

individual becomes a threat to the system.

The government may remove access privileges for contractor personnel

for unauthorized, negligent, or willful actions. These may include,

but are not limited to:

exploration of the system;

introduction of malicious software;

unauthorized modification or disclosure of the system or data;

and

failure to logoff.

There are other types of personnel security methods besides investigations such as employee statements regarding conflict of interest. Conflict of interest can include

procurement integrity certifications, financial disclosure, or reports on outside

activity. Be sure to specify what is required, when the form(s) must be completed

and what access decision(s) are based on the form.

If the agency has a computer systems user agreement that states user computer

security responsibilities (such as safeguarding passwords), it is appropriate to require

contractor personnel sign the agreement before computer systems access is granted.

The following clause can be modified to be more stringent (such as agency receipt

of agreement before access in granted).

The contractor shall insure that all contractor personnel sign the

user agreement (sample attached in Section J of RFP) prior to having

access to agency systems.

Care must be taken when addressing the area of contractor personnel. The

government cannot engage in personal services contracts unless specifically

authorized by statute. Personal services contracts are those where the government

has an employer-employee relationship with contractor staff. See Part 37 of the

FAR "Service Contracting." Requiring contractor personnel to be vetted as a

condition for employment under the contract suggests an employer-employee

relationship. However, requiring vetting of contractors as a condition for access to

government resources is different. It does not imply an employer-employee

relationship since the government has a responsibility to retain control of its resources.

60
While the distinction above may seem minor, it can be essential during a contract.

It is important that the distinction is understood to avoid personal services contracts

while protecting government resources.

61
I. Physical Security

The following types of clauses can be used for contracts where work will be

performed at the contractor location.

Physical security for computer systems helps prevent theft, tampering, and

destruction.

The contractor shall provide physical security for (list components

or systems) other than those in agency controlled space and for

information being transmitted across (list networks). Physical

security measures to be implemented include protecting the:

site (e.g., access to computer room);

hardware (e.g., communications processors, modems); and

software and data.

The contractor shall identify (name of system or components)

equipment that will be in nonagency controlled areas. Methods for

physically protecting these systems shall be provided by the

Contractor. The protection shall be against damage, unauthorized

access, alteration, modification and destruction, whether by act of

nature, accident, or intrusion.

Computer security should be considered as an issue for preaward site surveys. In

general, computer security should be integrated into existing agency clauses for

preaward site surveys instead of using this clause.

When it is determined that a preaward site survey is necessary in

order to verify that the security of a facility is adequate, the

contracting officer shall notify the offeror that such a survey will

be necessary and coordinate with the offeror as necessary. No

contract for services or supplies will be awarded until the survey

is completed. The recommendations of the (office performing

survey), as appropriate, will be a significant factor in the

determination of responsibility.

62
J. Computer Security Features in Systems

Computer security features in systems refer to specific functions to be incorporated

or bought with applications, operating systems, and hardware. How security features

are incorporated is dependent on the function and environment of the system.

For many systems, a combination of features will be used, some of which are incorporated in the operating system and some in the application. For example,

additional access controls at a finer level of granularity (record or field) and edit

checks are commonly incorporated at the application level, while file access may

still be performed by the operating system. Many other security architectures are

possible. Whatever security architecture is selected, it is imperative that the security

features work together in the system environment and that the documentation and

testing address the coordinated approach.

This section addresses several controls that are normally associated with operating

systems but can be provided by an application. Additional application-oriented

controls are described in FIPS PUB 73 Guidelines for Security of Computer

Applications.

The features described in this section are a combination of basic security controls

and some advanced controls. The controls are described in functional specifications.

Individual tailoring to specific environments will probably be required. If the

intention of the procurement is to acquire off-the-shelf products, market surveys

should be performed to determine what features are currently commercially available.

Modifying security features of off-the-shelf products can be expensive. (Market

surveys should be performed in accordance with agency policy.)

This section, like the other sections in this guidelines, is a list of possible features,

procedures, and assurances. Additional information on the uses of these features can be obtained from agency security officials and NIST and other publications. NIST

Publication List 91, which is periodically updated, catalogues the NIST computer

security publications. Technical terms and concepts are explained in the glossary.

Note: The term "system" is used loosely to mean any collection of components,

hardware, software, firmware, processes, etc. The use of a more specific term is recommended. Terms such as "the offeror's solution" for integration efforts, "the

product" for a component buy, "application system," "operating system," or specific

references to parts of the system architecture, i.e., "trusted computing base," are a few examples.

63
Note: The controls are consistent with those specified in DoD's 5200.28-STD. See

NCSL Bulletin Guidance to Federal Agencies on the Use of Trusted Systems

Technology.

J.l. Identification and Authentication Specifications

Identification and authentication are basic building blocks of security features in

systems. For many systems, every user initiated activity within the computer system

(e.g., accessing or printing a file, sending a message) should be attributable to a user of the system. The identification is normally performed when the user logs on to the system, whether through an interactive terminal, or through some other

mechanism (e.g., using a batch job, through a network connection). User

authentication is normally performed by use of a password. However, there are many methods of authentication. To enforce accountability and access control, all users must identify and authenticate themselves to the system.

The system shall include a mechanism to require users to uniquely

identify themselves to the system before beginning to perform any

other actions that the system is expected to mediate. Furthermore,

the system shall be able to maintain authentication data that

includes information for verifying the identity of individual users

(e.g., passwords). The system shall protect authentication data so

that it cannot be accessed by any unauthorized user. The system

shall be able to enforce individual accountability by providing the

capability to uniquely identify each individual computer system

user. The system shall also provide the capability of associating

this identity with all auditable actions taken by that individual.

The system shall be able to maintain information for determining the

authorizations of individual users.

The type of user authentication mechanism may need to be specified. The most

common type of authentication is passwords. NIST FIPS PUB 112 Standard on

Password Usage is a mandatory standard. In addition, DoD CSC-STD-00-85

Password Management Guideline contains further information on passwords.

There are several other types of authentication mechanisms. User authentication can

be based on three categories of information: something the user knows, such as a password; something the user possesses, such as a token; and some physical

characteristic (biometric) of the user, such as a fingerprint. Authentication methods

employing a token or biometric can provide a significantly higher level of security

than passwords alone. These systems are referred to as advanced authentication

technology. In addition, cryptography is often incorporated into advanced

authentication systems especially in network applications. NIST will be providing

guidance on advanced authentication.

64
J.2. Discretionary Access Control Specifications

Computer systems access control is the mechanism used to specify "who" (subjects) can do "what" to items controlled by the system or application (objects). The most

common types of access are read, write, modify, execute, and delete. The access

control is said to be discretionary when users on the system can pass access permissions to other users. This can be done directly or indirectly, such as copying

a file to a public area on the system.

(Note: The term "access control" is also used to refer to physical controls. This

section addresses the logical access provided by the computer system.)

The system shall use identification and authorization data to

determine user access to information. The system shall be able to

define and control access between subjects and objects in the

computer system. The enforcement mechanism (e.g., self /group/

public controls, access control lists) shall allow users to specify

and control sharing of those objects by other users, or defined

groups of users, or by both, and shall provide controls to limit

propagation of access rights. The discretionary access control

mechanism shall, either by explicit user action or by default,

provide that objects are protected from unauthorized access. These

access controls shall be capable of including or excluding access to

the granularity of a single user. Access permission to an object by

users not already possessing access permission shall only be

assigned by authorized users.

Commercial systems vary significantly with respect to the granularity of objects to which discretionary access control is applied. Generally, operating systems are organized to provide discretionary access control at the file level. In order to provide access control within an application, the government must specify the types

of objects, such as data elements, that are subject to the access control.

If system being acquired is to be delivered with access controls established, then the

government must provide a security policy, definition of data objects, and list of

access classes, access types, and accesses (who can do what) to the data objects.

J.3. Audit Specifications

Auditing provides protection in the sense that all meaningful actions within the

system may be recorded and some user held accountable for each action. Auditing

can occur at the operating system level or within a database or application. The

65
recorded audit data can assist the system security officer in determining who is

responsible for a problem or how a problem was caused. Audit data can be used to

deter users from attempting to exceed their authorizations and to achieve individual

accountability. The key to accountability in computer and network systems is the

recording and analysis of effective audit trail information.

Some system designers provide for the auditing of an event with mechanisms that

cannot be turned off by the operator, or system security officer. Other system

designers supply audit capabilities that can be turned on or off at the discretion of

the operator or security officer, thus allowing each local site to "tune" its auditing.

There are a number of tradeoffs that must be made in deciding what is to be

audited and how often.

The government is responsible for selecting which events have the potential to be

audited and, after system acquisition, which events are recorded in the audit trail. The government must also specify how long audit information is to be retained and

on what media. These decisions should be based on how the audit data will be

used.

The following is a three-part specification for auditing which should be modified for

the type of system being procured. The first part of the specification defines the

auditing function itself.

The system shall be able to create,

modification or unauthorized access

accesses to the objects it protects

protected so that read access to it

authorized.

maintain, and protect from

or destruction an audit trail of

The audit data shall be

is limited to those who are

The second part of this specification lists what types of events need to be auditable.

This list should be modified to include security events relevant to the system

function and environment.

The system shall be able to record the following types of events:

use of identification and authentication mechanisms, introduction of

objects into a user's address space (e.g., file open, program

initiation) , deletion of objects, and actions taken by computer

operators and system administrators and/or system security officers

and other security relevant events. The system shall also be able

to audit any override of human-readable output markings.

The third part of this audit specification is a description of the audit record.

For each recorded event, the audit record shall be able to identify:

date and time of the event, user, type of event, and success or

failure of the event. For identification/ authentication events the

66
origin of request (e.g., terminal ID) shall be included in the audit

record. For events that introduce an object into a user's address

space and for object deletion events, the audit record shall include

the name of the object and the object's label. The system

administrator shall be able to selectively audit the actions of any

one or more users based on individual identity and/or object label.

J.4. Cryptography Specifications

The following subsections address some of the ways cryptography can be used to provide computer security services in systems and some of the considerations for

using cryptography.

Cryptography can be used to provide confidentiality and integrity protection and can

be used in the generation of electronic signatures. Confidentiality of information can

be provided through encryption, which is the process of transforming information

from a human intelligible form to an unintelligible form. Integrity can be provided

through message authentication, which is a cryptographic process used to detect

unauthorized changes to information (transmitted or stored) in a computer system.

An electronic (cryptographic) signature is used as a replacement for a handwritten

signature.

Cryptography can be categorized as either secret key or public key. Secret key

cryptography is based on the use of a single cryptographic key shared between two

parties. The same key is used to encrypt and decrypt the data. Public key

cryptography uses two keys: a private key which is known only to its owner and a

public key which is distributed. Either the public or private key can be used to encrypt the data and the opposite key is used to decrypt it.

Choosing which type of cryptography should be implemented in a system is determined by several factors. An agency should consider the requirements of the

application and the types of services which can be provided by each type of

cryptography. It is possible that both secret key and public key cryptography are needed in one system; each performing different functions.

This section addresses three services provided by cryptography; encryption, data

authentication, and electronic signatures; and two areas that must be considered for

any system using cryptography: key management and security of cryptographic

modules.

67
J.4.a. Encryption

If encryption of sensitive but unclassified information (except Warner Amendment

information) is needed in a federal information processing system the use of the

Data Encryption Standard (DES), FIPS 46-1, is required unless a waiver is granted

by the head of the federal agency. The NCSL Bulletin on DES dated June 1990

provides an overview of DES, addresses its applicability, and describes waiver

procedures. Procurement initiators should be aware that software implementations of

the algorithm for operational use in general purpose computer systems currently do

not comply with the standard, and, if used, a waiver is required.

NIST provides a validation service for DES. A validation is required for

conformance with the standard. See section 4.f below and Appendix B for further

information on validations and assurances, including contract language.

The encryption provided by (the system or specific part of the

system as defined in the statement of work) shall be accomplished in

accordance with FIPS 46-1 Data Encryption Standard. (Select

validation language from Appendix B.)

In addition to specifying the cryptographic implementation, agencies should consider

other technical variables such as throughput, system interfaces, and data format.

While DES can work in any environment, the product that implements the DES may

have been customized for a particular environment.

Other important aspects of DES, such as key management and the security of the

modules, are addressed in sections 4.d and 4.e.

J.4.b. Data Authentication

DES is the basis for the Data Authentication Algorithm defined in FIPS 113,

Computer Data Authentication. The FIPS 113 provides integrity for information

using a cryptographic check value known as the Message Authentication Code

(MAC). Applying the DES algorithm, a MAC is calculated on and appended to

information. To verify that the information has not been modified at some later

time, the MAC is recalculated on the information. The new MAC is compared with

the MAC that was previously generated and if they are equal then the information

has not been altered. This standard should be used by agencies whenever

cryptographic authentication is needed for the detection of intentional modification of

information.

Note: FIPS 113 may be implemented in hardware, software, firmware, or any

combination thereof.

68
NIST provides a validation service for FIPS 113. Agencies may require that

offerors have products tested. For many applications, validation testing can provide

cost-effective assurance. See section 4.f below and Appendix B for further

information on validations and contract language.

The data/message authentication provided by (the system or specific

part of the system as defined in the statement of work) shall be

accomplished using message authentication codes as defined by FIPS

113. (Select validation language from Appendix B.)

J.4.c. Electronic Signature

Using cryptography, an electronic signature capability has been developed as a replacement of the handwritten signature. This capability can be used in ADP

systems anywhere a signature is required. For example, a signature may be needed

on an electronic letter, form, or message. Like the handwritten signature, the

electronic signature can be used to identify the originator or signer of ADP

information. Unlike its written counterpart, it also verifies that information has not

been altered after it was electronically signed.

An electronic signature can be generated using public key or secret key

cryptography. Using a public key system, documents in a computer system are

electronically signed by applying the originator's private key to the document. The

resulting digital signature and document are usually stored or transmitted together.

The signature can be verified using the public key of the signer. If the signature

verifies properly, the receiver has confidence that the document was signed by the

owner of the public key and that the message has not been altered after it was

signed. Because private keys are known only to their owner, it is also possible to

verify the signer of the information to any third party. A digital signature,

therefore, provides two distinct security services: nonrepudiation and message

integrity. Identifying that electronic information was actually signed by the claimed

originator to a third party provides nonrepudiation. Determining that information

was not altered after it was signed provides message integrity. NIST currently has

a draft Digital Signature Standard (DSS), which has not yet been assigned a FIPS

number.

NIST is planning on providing a validation service for the DSS. A validation will

be required for conformance with the standard after NIST establishes the validation

program. See section 4.f below and Appendix B for further information on

validations and assurances, including contract language.

The following contract clause should not be used until the draft FIPS is finalized.

69
The public key-based digital signature capability provided by (the

system or specific part of the system as defined in the statement of

work) shall be accomplished in accordance with the Digital Signature

Standard (insert FIPS number). (Select validation language from

Appendix B .

Using DES, a secret key algorithm, a MAC (a cryptographic check value) can be

used to provide an electronic signature capability. Calculating a MAC on

information in an ADP system provides message integrity as described in section 4.b

above. A MAC can be used to identify the signer of information to the receiver.

However, the implementations of this technology do not inherently provide

nonrepudiation because both the sender of the information and the receiver of

information share the same key.

The electronic signature capability provided by (the system or

specific part of the system as defined in the statement of work)

shall be accomplished in accordance with FIPS 113. (Select

validation language from Appendix B.)

J.4.d. Key Management

Key management is extremely important because the security of any cryptographic

system is dependent on the security provided to the cryptographic keys. In order for a cryptographic system to work effectively, keys must be generated, distributed,

used, and destroyed securely. Key management is an issue in both secret key

systems, such as DES, and public key systems. This section addresses secret key

systems.

NIST has developed a draft FIPS PUB for the management of cryptographic keying

material utilizing the Data Encryption Standard. (A FIPS number has not yet been

assigned.) The draft FIPS PUB adopts ANSI X9.17 and specifies a particular

selection of options for the automated distribution of keying material by the Federal

Government. This standard must be used by Federal agencies when designing,

acquiring, implementing and managing keying material which use DES and ANSI

X9.17. Other key management systems may be approved by NIST for federal

government use in the future.

NIST provides a validation service for selected options of ANSI X9.17 and is developing services for the new FIPS. Agencies may require that offerors have

products tested. For many applications, validation testing can provide cost-effective assurance. See section 4.f below and Appendix B for further information on

validations and assurances, including contract language.

70
The following contract clause should not be used until the draft FIPS is finalized.

Make sure that the validation section of the clause only specifies options for which

NIST is currently providing validation services.

The key management provided by (the system or specific part of the

system as defined in the statement of work) shall be accomplished in

accordance with (insert FIPS number)

.

Key management can be a complex issue for large or diverse systems. Be sure to request a key management system that meets the system's specific needs.

J.4.e. Security of Cryptographic Modules

The security of cryptographic modules refers to the secure design, implementation

and use of a cryptographic module. The security of cryptographic modules is important because cryptography is often relied on as the exclusive means of

protecting data when the data is outside the control of the system. The protection

of the data is, therefore, reliant on the correct operation of the cryptographic

module. The knowledge that a module is operating correctly is referred to as assurance. Appendix B and section III.B.l.b further discuss assurance.

Proposed FIPS PUB 140-1 Security Requirements for Cryptographic Standards

establishes the physical and logical security requirements for the design and

manufacture of cryptographic modules used to protect sensitive unclassified

information. Note: FIPS 140-1 can be used to provide assurance for DES and

other NIST-approved cryptographic algorithms, such as the public key algorithm

used in the digital signature standard.

FIPS 140-1 defines four levels of security, with Level 1 being the lowest and Level

4 being the highest. Based on the level of assurance analysis performed during the

security requirements phase (sec. III.B.l.b), an appropriate FIPS 140-1 level should

be identified. NIST may provide additional information which will help agencies

identify the appropriate level. The identification of the security level should be

specified in the procurement package.

FIPS 140-1 will replace FIPS 140, General Security Requirements for Equipment

Using the Data Encryption Standard (formerly Federal Standard 1027). Currently

agencies must require conformance with FIPS 140 (or obtain a waiver) if cryptography is used to protect sensitive unclassified information. Since testing is no longer available for FIPS 140, agencies cannot require validation testing. Instead,

agencies should require an offeror's declaration of FIPS 140 conformance or, if available, an NSA endorsement. After FIPS 140-1 becomes a standard, agencies

should continue to require a declaration of conformance until NIST establishes the

71
validation service. Only then can agencies require FIPS 140-1 validations. The

CSL Bulletin, "FIPS 140 - A Standard In Transition," dated April 1991, provides

additional information on the standard and the waiver procedure.

When FIPS 140-1 becomes a standard and NIST has established the validation

program, the following clause can be used. A validation will be required for

conformance with the standard. See section 4.f below and Appendix B for further

information on validations and assurances, including contract language. These

clauses should not be used until FIPS 140-1 is finalized.

The design, implementation, and use of the cryptographic module

provided by (the system or specific part of the system as defined in

the statement of work) shall be in conformance with FIPS 140-1,

Level (insert level). (Select validation language from Appendix B.)

J.4.f. Validations

NIST currently provides validation services for FIPS 46-1, FIPS 113, and selected

options of ANSI X9.17. After an implementation is validated, NIST issues a

validation certificate and adds the implementation to a Validation List. (Lists for

validated implementations are available by contacting NIST or through their

electronic bulletin board service, 301-948-5717 or from the NIST Validated Products

List, updated quarterly.) Manufacturers, integrators, and offerors may purchase

validated implementations and use them in their own products. As long as the

validated implementation has not been altered, a second validation is not performed.

Therefore, the product containing the validated implementation would not be on the

validation list; however, the offeror should be able to identify the validated

implementation used in the product or supply a copy of the original validation

certificate.

See Appendix B for more information on validations and assurance. Appendix B

specifically addresses options for validation testing and provides contract language.

Other Sources

NIST has other standards and guidelines that relate to cryptography. A list of NIST

publications is available from NIST Publications List 91. For ordering information,

see the inside back cover of this document.

72
J.5. Object Reuse Specifications

When a system resource (memory or storage) is reused, there is a possibility that the

new user can view "residual information" left in the resource by the previous user. The purpose of object reuse specifications is to prevent the inadvertent disclosure of

residual information. Since object reuse may impact system performance, care should be taken in selecting and testing object reuse.

The system shall be able to ensure that all authorizations to the

information contained within an object are revoked prior to initial

assignment, allocation or reallocation to a subject from the

system's pool of unused objects. The system shall be able to ensure

that no information, including encrypted representations of

information, produced by a prior subject's actions is available to

any subject that obtains access to an object that has been released

back to the system.

Object reuse specifications can be achieved either by clearing objects upon allocation or upon deallocation. A third method involves establishing a "high water mark"

sensitivity of the object, allocating it only to processes of the same sensitivity.

Objects can be cleared by overwriting each bit in the object. The minimum

number of overwrites should be specified.

J.6. System Integrity Specifications

The government can use commercial off-the-shelf diagnostic capability for validating

correctness of the hardware and firmware operations. Generally speaking such

diagnostic offerings are not valid to verify the correctness of the software

implementation.

Hardware and/or software features shall be provided that can be used

to periodically validate the correct operation of the on-site

hardware and firmware elements of the system.

In addition, some vendors are using cryptographic techniques to verify the integrity

of their software. These can be used to ensure that software received, or in storage,

is the same as the "master" copy of the software maintained by the vendor.

J.7. System Architecture Specifications

As described in Appendix B, "Assurance," the use of advanced system architectures can provide assurance that the security features are correctly and effectively

implemented.

73
The mechanisms within the application that enforce the access

control shall be continuously protected against tampering and/or

unauthorized changes.

The security-relevant software shall maintain a domain for its own

execution that protects its security mechanisms from external

interference or tampering (e.g., by modification of its code or data

structures) . Resources controlled by the system may be a defined

subset of the subjects and objects in the computer system. The

system shall maintain process isolation through the provision of

distinct address spaces under its control. The system shall isolate

the resources to be protected so they are controlled by the access

control and auditing requirements.

Note: The word "domain" as used here refers to the protection environment in

which a process is executing. Domain is sometimes also referred to as "context" or "address space."

The procuring agency should be aware that over specification of the architecture for a system can preclude integrators from incorporating otherwise valid existing

products. Over specification can also eliminate lower cost alternatives resulting in a more costly procurement. This over specification is a common problem and

generally proves not to be cost effective. From a security perspective over

specification can actually preclude adequate information control.

J.8. Labels and Mandatory Access Control

The following sections address labels and mandatory access control. These are emerging security features in some off-the-shelf operating systems which may be

appropriate for use in some computing environments. They are not required.

This section presents a brief introduction to and specification language for labels and

mandatory access control. Labels and mandatory access control should not be

acquired or implemented without a thorough knowledge of access control policy,

information flow, and how labels and mandatory access control work. Labels and

mandatory access control can be costly in terms of dollars, ease of use, ease of

administration, and computer resources.

These sections on labels and mandatory access control are addressing only one form

of mandatory access. Other approaches, such as those based on roles, are possible,

section J.9 addresses labels; section J. 10 addresses mandatory access controls. For

additional guidance, the procurement initiator should contact the agency security

official.

74
Labels and mandatory access control are useful when acquiring multi-user computer

systems with a requirement for mandatory separation of sensitive information and for

which security labels can be established. In practical terms, this means labels and

mandatory access control are most useful if the type and degree of sensitivity of the

data can be established, and there is a strong reason for using technical means to enforce compliance with policy. Labeling and mandatory access control require that

there is a clear access control policy that can be enforced.

J.9. Label Specifications

Labels can be used to have the system manage sensitive objects. A label is a piece

of information that represents information about an object or subject. Labels can be

used for a variety of purposes including access control, specifying protective

measures, and indicating additional handling instructions. This document addresses

using labels for access control. It should be modified if the labels will be used for

other purposes. If labels are used for access control, then object labels represent the

degree and type of sensitivity of the data in an object. Subject labels represent the

authorization of users to access degrees and types of sensitive data.

Security labels associated with each subject and storage object

under the system's control (e.g., process, file, segment, device)

shall be maintained by the system. These labels shall be used as

the basis for access control decisions. In order to import

nonlabeled data, the system shall be able to request and receive

from an authorized user (e.g., system or application security

administrator) the security label of the data, and all such actions

shall be auditable by the system.

In order to ensure smooth transition in the operating conditions of the system when

changes are necessary, and also for maintenance purposes, it is sometimes necessary

to provide capabilities that allow the security labels of objects to be altered under

carefully controlled conditions.

The system shall ensure that any feature that changes security

labels is only invocable by an authorized individual under the

direct control of the system, or by a part of the system, and that

these actions are subject to auditing requirements.

J.9.a. Label Integrity Specifications

The following specification addresses integrity requirements for labels. Depending

on system architecture, it is not essential that a label be maintained with the data.

75
It is permissible to associate the label with the data. Some operating systems

maintain the label inside the operating system and store the data separately.

Security labels shall accurately represent the degree and type of

sensitivity of the specific subjects or objects with which they are

associated. Throughout the system, security labels shall accurately

and unambiguously represent and be associated with the information

being managed.

J.9.b. Labels and Input/Output Specifications

Since all systems receive input (import data) and produce output (export data), the

system designer must address the problem of what to do with labels at system

boundaries. How is incoming data labeled? How is outgoing data labeled? The

input and output can be in electronic, paper, or other form.

The system shall be able to designate each communication channel and

I/O device as either single-label or multi-label. Any change in

this designation shall be done by a properly authorized individual

and shall be audi table by the system. The system shall maintain and

be able to audit any change in the security label or labels

associated with a communication channel or I/O device.

The Phrase "Properly Authorized" is understood to be the System Administrator and

Security Officer or their designees.

J.9.b(l) Multi-Label Communications

When information contained in an object is exported from the system, a means must

be provided for the system to accurately and unambiguously associate the security

label of the object with the information being exported. The Phrase "exported by

the system" is understood to include transmission of information from an object in

one system to an object in another system. The form of internal security labels may

differ from their external (exported) form, but the meaning must be retained. This

association is critical on multi-label channels because the receiver will use the

provided label both for processing and access decisions.

When the system exports an object to a multi-label I/O device, the

security label associated with that object shall also be exported

and shall reside on the same physical medium as the exported

information and shall be in the same form (i.e., machine-readable or

human-readable form) . When the system exports or imports an object

over a multi-label communication channel, the protocol used on that

channel shall provide for the unambiguous pairing between the

76
security labels and the associated information that is sent or

received

.

J.9.b(2) Single-Label Communications

Two types of single label designations are possible. One type can be applied to a channel or device by a Security Administrator. The second type can be applied by

an authorized user (e.g., application security administrator) who can designate which

label, within a range, is to be applied to the subsequent data/object. Thus a device

or channel may be multiple consecutive single labels; but the system must

communicate with an authorized user prior to each label designation change.

Single-label I/O devices and single-label communication channels are

not required to maintain the security labels of the information they

process. However, the system shall include a mechanism by which the

system and an authorized user (e.g., application security

administrator) reliably communicate to designate the single security

label of information imported or exported via single-label

communication channels or I/O devices.

J.9.b(3) Labeling Output

The following specifications address exporting data to a different environment, for

example, from the internal system environment to the office environment or a networked environment.

Prior to releasing an object to an environment where accesses are no

longer mediated by the system, the system must associate the object

with an external label that is comprehensible to the new

environment. The external label must accurately represent the

security label of the object as assigned by the system.

One of the most common examples of moving a label into a new environment is labeling human-readable output, specifically printouts. The following specification is an example of how the system can label printouts.

The system administrator shall be able to specify the printable

label names associated with exported security labels. The system

shall mark the beginning and end of all human-readable, paged,

hardcopy output (e.g., line printer output) with human-readable

security labels that properly represent the overall sensitivity of

the output. The system shall, by default, mark the top and bottom

of each page of human-readable, paged, hardcopy output (e.g., line

printer output) with human- readable security labels that properly

represent the overall sensitivity of the output or that properly

77
represent the sensitivity of the information on the page. The

system shall, by default and in an appropriate manner, mark other

forms of human-readable output (e.g., maps, graphics) with

human-readable security labels that properly represent the

sensitivity of the output. Any override of these marking defaults

shall be auditable by the system.

The system administrator is usually the "user" designated to specify the printed or displayed security label that is to be associated with exported information.

J.10. Mandatory Access Control Specifications

As stated in section 2, access control is the mechanism used to specify "who" can do "what" to items controlled by the system. The most common types of access are

read, write, modify, execute, and delete. The access control is said to be mandatory

when the system mediates access based on subject and object labels. This prevents

users from accidentally or deliberately violating the access control policy.

The system shall be able to enforce a mandatory access control

policy over all subjects and storage objects (e.g., processes,

files, segments, devices) . These subjects and objects shall be

assigned security labels and shall be used as the basis for

mandatory access control decisions. The system shall be able to

support two or more such labels. The following requirements shall

hold for all accesses between subjects and objects controlled by the

system

A subject can read an object only if the hierarchical attribute

in the subject's label is greater than or equal to the

hierarchical attribute in the object's label and the

nonhierarchical attribute in the subject's label include all

the nonhierarchical attributes in the object's label.

A subject can write an object only if the hierarchical

attribute in the subject's label is less than or equal to the

hierarchical attribute in the object's label and all the

nonhierarchical attributes in the subject's label are included

in the nonhierarchical labels in the object's label.

Identification shall be used by the system to ensure that the

authorization of subjects created to act on behalf of the

individual user are a subset of the authorization of that user.

78
Appendix A

Uniform Contract Format for Federal Government

Requests For Proposals (RFP)

RFP Section Contents Created By Technical

and/or Procurement

Comments

A. Solicitation/Contract

Form

Cover Sheet For RFP, with

Solicitation Number,

Type of Solicitation,

Due Date,

Procurement Contact

Point, etc. (SF33)

B. Supplies or Services List of Products/Services

and Prices/Costs to Be Provided by Offeror

Procurement

Contains standard RFP

information

Procurement

Developed from other

portions of RFP.

Contains standard RFP

information.

C. Description/

Specifications/

Work Statement

D.

E.

Packaging and

Marking

Inspection and

Acceptance

Defines Scope of Contract

and Requirements Including:

Mandatory Specifications,

Optional Features Services

Specification may be included

as an Attachment/Section J

Shipping, Handling, and

Storage Requirements.

May Not Be Required For

Service Contracts.

Standards of Performance,

Reliability Requirements,

Acceptance, Benchmarks,

Inspection, Quality Assurance

Technical & Procurement

Describes product/services

to be procured.

Procurement & Technical

Standard RFP information

with special technical

requirements if necessary.

Procurement & Technical

Determines how product

or service is to be

accepted and must

79
Deliveries or Performance

Time, Place, and Method of

Deliverables/Performance.

Describes such things as: Liquidated Damages,

Equipment Replacement,

Field Modifications,

Alternations, Maintenance

Response Time and Down Time

Credits, Product Replacement,

Variation in Quantity,

Delivery and Installation

Schedule, Stop Work Orders,

Etc.

perform. Contains

standard RFP information

with specific technical

requirements.

Procurement & Technical

Contains standard RFP

information with special

technical requirements.

G. Contract

Administration

Data

Contract Administration such

as: Authorities of Government

Personnel, Required Reports,

Holidays, Use of Government

Property, Financial

Information

Procurement & usually

Technical

Normally standard RFP

information with special

technical requirements.

H. Special Contract

Requirements

I. Contract Clauses

Clauses Other Than Those

Required By Law/Regulations

Including:

Warranties, Replacement

Parts, Engineering Changes

Recording Devices,

Hardware/Software Monitors,

Site Preparation, Financial

Reporting, Transition

Requirements, Handling of

Data, Security, Etc.

Clauses Required By Law/

Regulations not Otherwise

Required for a Particular

Section.

Procurement & Technical

Normally standard RFP

information with special

technical requirements.

Procurement

Contains standard RFP

information

80
J. List of Attachments

K. Representations,

Certifications, and

Other Statements

of Offerors

L.

M. Evaluation Factors

For Award

Any Additional Procurement

and Technical Information

For Offeror.

All Statements Required of

the Offeror by Law/

Regulation/Agency

.

Offeror Must Complete and

Return with proposal.

Describes How Proposals

Will Be Evaluated and the

criteria against which

proposal will be evaluated.

Also Describes how a Source

will be selected.

Procurement & Technical

Procurement

Standard RFP information

Procurement & Technical

Addresses how offeror

should respond to

statement of work as set out in the evaluation

criteria.

Procurement & Technical

Instructions, Requirements for Proposals.

Conditions, and Specifies the Plans,

Notices to Offerors Approaches, References, and

Other Information the

Offeror Must Submit for

Proposal Evaluation.

Requires Offeror To Tell

How They Will/Can Meet The

Requirements Described In

Section C.

For further information, see FAR 15.406.

81

Assurance

Appendix B

There are many methods of attaining assurance that the security features work as proposed. Since assurance methods tend to be qualitative rather than quantitative,

they will need to be evaluated. Assurance can also be quite expensive, especially if

extensive testing is done. It is useful to evaluate the amount of assurance received

against the cost to make a best value decision. It is important to consider assurance methods within the context of the statement of work, evaluation plan, and

acceptance test plan.

The selection of assurance methods should be consistent with and follow from the

requirements analysis, especially from the risk analysis. Since some of the methods

are impossible for certain types of federal information processing (FIP) acquisition or

are restrictive of competition, care must be taken in selection. See the note on

assurance and competition at the end of this appendix.

It will normally be best to use a combination of methods. Each method has

strengths and weaknesses in terms of cost and what kind of assurance is actually

being delivered. None are foolproof. Each method has restrictions. An accrediting

and/or certifying official or computer security official can help determine the

strengths and weaknesses of each method based on the type of system(s) being

procured.

Many of these assurances are evaluations. Care must be taken to know what

evaluation criteria were used and exactly what the evaluation means. Evaluations

and testing all have limits. No organization can afford to test every possibility

including how the evaluated item interacts with other system components.

Methods

Testing/quality assurance. There are many techniques that have been developed

for use with "critical" or high assurance systems. These techniques can be applied

to security software. These development and acceptance techniques provide

assurance for systems. The following NIST publications provide further explanation:

FIPS PUB 101 Guideline for Lifecycle Validation, Verification, and

Testing of Computer Software

FIPS PUB 132 Guideline for Software Verification and Validation Plans

SP 500-144 Guidance on Software Package Selection

83
SP 500-165 Software Verification and Validation: Its Role in

Computer Assurance and Its Relationship with Software

Product Management Standards

SP 500-180 Guide to Software Acceptance

Agency quality assurance, safety, or reliability personnel may also be able to provide

assistance. The contractor developing the system or application can provide security

testing. The development and acceptance testing can also be done by an independent validation and verification contractor (IV&V). If testing is going to be

done by an independent contractor, this needs to be specified in the RFP.

NIST conformance testing and validation suites. NIST produces validation suites

and conformance testing to determine if a product (software, hardware, firmware)

meets specified standards. These test suites are developed for specific projects and

use many methods. New test suites are being developed. In general, testing is performed by the vendor and validated by NIST, or testing is performed by a

certified laboratory. Following are examples of two types of NIST computer

security testing:

DES implementation testing (reference Special Publication 500-20). To

validate the correctness of the implementation, vendors run specified tests and

send the results to NIST. If the vendor passes the test, NIST issues a

validation certificate.

FIPS PUB 113 data authentication algorithm testing and ANSI X9.17 key

management for point-to-point environments. Vendors connect to a NIST

bulletin board that interactively runs the test suite for the selected standard.

If the vendor passes the test, NIST issues a validation certificate.

Evaluations by government agencies. Government agencies evaluate products for use in their environments. These evaluations may or may not be published. It is important to ask offerors to supply evaluation results as part of an assurance package. These evaluations are normally not endorsements by the agencies.

NSA's Evaluated Products List (EPL). The National Security Agency

(NSA) evaluates some computer operating systems and security packages

against DoD 5200.28-STD, Trusted Computer Systems Evaluation Criteria

(TCSEC or Orange Book).

Evaluations by independent organizations. Trade and professional organizations

are possible sources of independent evaluations. Ask offerors to provide information

on evaluations which they consider pertinent to their proposal.

84
Evaluations by another vendor. Private commercial organizations may offer

product assurance testing and evaluations. These may lack the independence of

government and trade organization evaluations.

Evaluations by another government. Other governments, including several

European governments and Canada, are researching evaluation techniques and

criteria. Care should be taken to observe the differences in environments and

governmental priorities.

Product has been accredited to operate in similar situation. Once again, these

accreditations are not published. It is important to ask offerors to supply the

accreditation results. These, even more so than evaluations, are not normally

endorsements. Accreditations are environment and system specific. Since

accreditation balance risk against advantages, the same product may be accredited

for one environment but not for another.

Self-certification following a formal procedure, e.g., FIPS 102. A vendor selfcertification does not rely on the work of an impartial or independent reviewer. It is a vendor's technical evaluation of a system to see how well it meets an internally

stated security requirement. Even though this method does not provide an impartial

review, it can still provide some assurance. The vendor's reputation is put on the

line and a certification report can be read to determine if the security requirement

was defined and if a meaningful review was performed.

Self-certification under the auspices/review of an independent organization.

This method may be able to combine the lower cost and greater speed of a selfcertification with the impartiality of an independent review. The review, however,

may not be as thorough as an evaluation or testing.

Warranties, Integrity Statements and Liabilities. Warranties are another source of

assurance. If a manufacturer/producer is willing to correct errors within certain time

frames or by the next release, this should give the purchaser a sense of commitment

to the product and of product quality. An integrity statement is a formal declaration

or certification of the product. It can be backed up by a promise to (a) fix the item

(warranty) or (b) pay for losses (liability) if the product does not conform to the

integrity statement. See section IV.E, "Legal Issues," for more information.

Manufacturer's published assertions. A manufacturer's or developer's published

assertion or formal declaration provides assurance based on their reputation.

Assurance documentation. There are several types of assurance documentation.

Descriptions are provided in section IV.D, "Documentation."

85
Use of advanced or trusted development. Offerors may provide documentation to

show that they have used advanced or trusted system architectures, development

methodologies, or software engineering techniques. Use of the trusted computing

base (TCB) concept, formal modeling, and mathematical proofs are some examples.

Offerors should describe how these techniques and methodologies were employed

and how they help protect the system. (A specification for a trusted computer base

architecture is included in "Features in Systems," sec. IV.J.7.)

Assurance Methods and Competition.

Since not all assurance methods are equally available to all vendors, requiring any

one assurance method can limit competition. This is especially true for evaluations.

If the government specifies that a product pass a certain test to get on a list of

"qualified" products before it is acquired, then there may be special rules that must

be followed. FAR 9.2 addresses qualified products.

The government, according to a basic procurement philosophy, tries to maintain a

"level playing field" while providing incentive for vendors to provide advanced

products. Requiring that a vendor use an assurance method that is not accessible by

all vendors limits competition and may preclude the government from considering

new ideas.

There are many methods for increasing competition while still meeting the

government's requirements. Discuss with the contracting officer the use of scoring assurance methods or providing incentives and disincentives. These can be used to

"give credit" to offerors who have had their products evaluated while maintaining

full and open competition.

Note: In a scoring scheme, it must be possible for an offeror to gain the maximum

number of points possible using assurance methods that are equally accessible to all.

Contract Language for Validation Testing

The following considerations and contract language, based on the Federal ADP &

Telecommunications Standards Index, can be used to help increase assurance and

promote competition. Although the clauses are addressed to the use of NIST

conformance and validation testing, they can be modified for use with other forms

of assurance. (Note: Some NIST validations, such as DES validations, are required

and some are optional.)

Testing and validations can be performed at several stages during an acquisition.

These clauses address three types of testing: delayed validation, prior validation

testing, and prior validation. For delayed validation and prior validation testing, be

86
sure to customize the time frame parameter in Part 2 of the solicitation wording to ensure that any resubmissions for validations are done in a timely manner.

Delayed Validation. When an agency determines that the nature of the requirement

is such that implementations of a HPS may be offered that have not yet been tested

for conformance to that FIPS or if an implementation of the FIPS will be developed

during the course of the contract, the "Delayed Validation" solicitation wording

option should be used.

Prior Validation Testing. When an agency determines that it is essential for

implementation of a FIPS to be previously tested for conformance to that FIPS

before being offered, and the nature of the requirement is such that an implementation of a FIPS may be initially offered that has not been fully validated

(i.e., implementation has not fully demonstrated compliance to the FIPS), the "Prior

Validation Testing" solicitation wording option should be used. For example, some

validation procedures, especially for complex FIPS, allow for stages within the

process.

Prior Validation. When an agency determines that it is essential for

implementations of a FIPS be validated (i.e., implementation has been tested and has

demonstrated compliance to the FIPS) for conformance to that FIPS prior to being

offered the "Prior Validation" solicitation wording option should be used.

Solicitation Wording: Validation of FIPS Implementations

This clause can be modified to address particular FIPS and particular system

components. Within a solicitation, different testing options can be specified for

different components.

In addition to the FIPS implementation requirements specified

elsewhere in this requirements document, all implementations of FIPS

that are brought into the Federal inventory as a result of this

document for which validation is specified, and those implementation

used by vendors to develop programs or provide services shall be

validated using the official validation system specified by the

National Institute of Standards and Technology (NIST) Computer

Systems Laboratory (CSL) . Validation shall be in accordance with

CSL validation procedures for that FIPS. The results of validation

shall be used to confirm that the implementation meets the

requirements of the applicable FIPS as specified in this document.

To be considered responsive the offeror shall:

(1) Provide validated FIPS implementation through (select testing

option and insert appropriate paragraph from below: "Delayed

Validation," "Prior Validation Testing" or "Prior Validation.")

87
(2) Agree to correct all implementation nonconformance from the

applicable FIPS reflected in the validation summary report not

previously covered by a waiver. All areas of nonconformance must be

corrected within 12 months (or other time frame) from the date of

contract award (or from the date of the summary report) unless

otherwise specified in this document. If an interpretation of the

FIPS is required that will invoke the procedures set forth in FIPS

PUB 29-2, such a request for interpretation shall be made within 30

calendar days after contract award. Any corrections that are

required as a result of decision made under the procedures of FIPS

PUB 29-2 shall be completed within 12 months of the date of the

formal notification to the contractor of the approval of the

interpretation. Proof of correction in either case shall be in the

form of a CSL Certificate of Validation or registered validation

summary report for the corrected implementation. Failure to make

required corrections within the time limits set forth above shall be

deemed a failure to deliver required material. The liquidated

damages as specified for failure to deliver the operating system or

other system component (software, hardware or firmware) shall apply.

Testing Options:

"Delayed Validation"

The offeror shall certify in the offer that all implementation

of FIPS, including applicable FIPS options, offered or

developed in response to this document will be submitted for

validation. If the implementations are to be developed they

shall be submitted for validation upon delivery. If the

implementations are available and have not been previously

tested or validated then the implementations shall be submitted

for validation upon contract award. In either case, when the

implementation is submitted for validation the submission shall

include a request to have the validation be completed at the

earliest possible date permitted by the CSL validation

procedures. Unless specified elsewhere, proof of submission

for validation shall be in the form of a letter scheduling the

validation and the subsequent delivery by the offeror of a CSL

registered report or CSL certificate immediately upon receipt

thereof. Proof of testing shall be provided in the form of a

CSL registered validation summary report. Proof of validation

shall be in the form of a CSL Certificate of Validation.

"Prior Validation Testing"

The offeror shall certify in the offer that all implementations

of FIPS, including applicable FIPS options, offered in response

to this document have been previously tested or validated and

88
included on the current list of validated products maintained

by the Computer Systems Laboratory (CSL) . Unless specified

elsewhere, proof of testing shall be provided in the form of a CSL registered validation summary report. Proof of validation

shall be in the form of a CSL Certificate of Validation.

"Prior Validation"

The offeror shall certify in the offer that all implementation

of FIPS, including applicable FIPS options, offered in response

to this document have been previously validated and included on

the current list of validated products maintained by Computer

Systems Laboratory (CSL) . Unless specified elsewhere, proof of

validation shall be in the form of a CSL Certificate of

Validation

89

Appendix C

Planning Phase Risk Analysis

A planning phase risk analysis is similar to a "regular" risk analysis. They share

the same goal and overall strategy. The goal is to identify vulnerabilities and

offsetting controls. The logical outcome of any risk analysis is the acquisition

and/or implementation of cost-effective security controls. This is often referred to as the risk reduction phase. (Another product of the risk analysis is the identification

of residual risk which cannot be further reduced or eliminated in an economically

feasible manner by currently available means.)

The strategy of a risk analysis is to examine potential losses that may result from

weaknesses in system security and the damage that may result from the occurrence

of certain threats. In order to do this, a risk analysis contains the following

components:

Asset identification and valuation

Threat analysis

Vulnerability assessment

Impact analysis

Determination of risk

Since the goal of a risk analysis is the selection of cost-effective safeguards, a risk

analysis is actually a decision-support tool. By identifying those areas with the

greatest potential for loss or harm, the risk analysis provides a basis for a system

manager to make informed choices about controls. This allows the manager to allocate precious resources based on need and expected effectiveness.

The planning phase risk analysis is performed during the planning stage of system

acquisition and during the design stage of a system life cycle. As discussed in

section III.B.l.b and section III.B.2, this analysis is used as a basis for deciding

which safeguards are mandatory and which are desirable. The analysis should,

therefore, concentrate on items that are related to system acquisition decisions. In

addition, it will help support the evaluation plan's ranking of the desirable

safeguards.

As the term "planning phase" implies, further risk analysis is required during the life

of a system. OMB Circular A- 130 requires periodic risk analysis for general

support systems. However, depending on the nature of the system, how it is being

developed or acquired, and other factors, there are many places during the systems

life when a form of risk analysis may be useful. In general, risk analysis should be

91
viewed as an iterative process to take into account changes in the system, the

system environment, and knowledge about the system. The nature of the risk

analysis should always be commensurate with the placement in the systems life and

the sensitivity of the system.

How to Perform a Planning Phase Risk Analysis

Although a planning phase risk analysis is very much like a risk analysis, there are

differences. A planning phase risk analysis is less precise. The analysis considers

projected costs, assets, threats and vulnerabilities, not current ones. The impacts of

failures are based on a projection of system use. The emphasis of risk analysis is

the assessment of existing assets and controls. The planning phase risk analysis

emphasizes the impacts of possible security problems and how to mitigate them.

The planning phase risk analysis should be performed in keeping with federal and

agency guidance. The agency risk analysis office or computer security office should

be consulted.

The planning phase risk analysis need not be a large and complex document. It should focus on defining and documenting system security requirements. The

purpose of a risk analysis is not to spend a lot of time trying to quantify or describe

assets and impacts but to provide a basis for making informed decisions about

system security. Therefore, the level of detail should be commensurate with the

sensitivity of the system and the need for decision support.

Existing agency risk analyses can be used as a starting point. Since many

information processing resources are bought as part of either an existing facility,

application, or system, many aspects including physical, application, user, and facility

environment may already be known.

A planning phase risk analysis methodology based on the FIRMR, Federal

Information Processing Standard Publication (FIPS PUB) 73 and other source

material is presented in GAO Report Agencies Overlook Security Controls During

Development (GAO/IMTEC-88-11S) and reprinted below. Additional material on

risk analysis is available from the sources referenced in the GAO report and from:

Special Publication 500-174 Guide for Selecting Automated Risk Analysis Tools

NISTIR 4325 U.S. Department of Energy Risk Assessment

Methodology

NISTIR 4749 Sample Statements of Work for Federal Computer

Security Services.

92
GAO Methodology

This is a risk methodology, based on a system development life cycle, published by

the GAO. Agencies can use other methodologies or modify this one. Nothing in

this methodology is required. The methodology does not provide much detail; the

references cited above and in the methodology can be used to provide additional

guidance. (Note: FIRMR citations are from the 1988 version.)

Initial Risks

1. Identify the impact of major failure including:

a. an analysis of expected losses calculated in dollars or other significant

indicators (FIRMR, Section 201-7.103-2) such as (FIPS 73, p. 27):

1. extent of inconvenience or hardship to individuals.

2. extent of lives lost. 3. extent of disruption to the national economy or national security.

b. an analysis of, but is not limited to, the impact of the following risks

(FIRMR, Section 201-7.103-2):

1. physical destruction or loss of data and program files (also in

FIPS 73, p. 27; FIPS 31, p. 10).

2. theft or disclosure of information (also in FIPS 73, p. 7), data

confidentiality issues (FIPS 65, p. 9), improper dissemination and

careless disposal (FIPS 41, p. 12)

3. misuse of ADP system, that is, fraud, vandalism, etc., (see also

falsified data, FIPS 73, p. 27; theft of information or assets,

FIPS 31, p. 10).

4. delay or prevention of ADP operation (see also unavailable data

or services, FIPS 73, p. 27).

5. lack of reliability of automated data processing equipment and

utilities.

6. altered or inaccurate data (also in FIPS 73, p. 25).

c. potential impacts are assessed for every application that will maintain

or process sensitive or mission-critical information (implied in FIPS 73,

p. 27).

2. Estimate the frequency of major failure in the areas of:

a. inaccurate data,

b. falsified data,

c. disclosed data,

d. lost data or programs, and

e. unavailable data or services (FIPS 73, p. 27).

93
3. Estimate the cost of major failures:

a. Calculate an annual loss expectancy that combines the estimates of the

value of potential loss and probability of loss (FIPS 31, p. 11). See

prior risk section (2C.1.,2) for the impact and frequency of failure

estimates that the agency should include in its analysis.

b. Remedial security measures are identified to address significant threats

(FIPS 31, p. 13) and vulnerabilities (FIPS 73, p. 25), including

measures such as:

1. altering the environment (FIPS 31, p. 13),

2. erecting barriers (FIPS 31, p. 13),

3. improving procedures (FIPS 31, p. 13),

4. early detection (FIPS 31, p. 13), and

5. contingency plans (FIPS 31, p. 13).

c. The cost of remedial measures is identified including an identification

of the least cost mix of security measures (FIPS 31, p. 13).

94
GLOSSARY

Appendix D

Acceptance The act of an authorized representative of the government by which

the government, for itself or as agent of another, assumes control or ownership of

existing identified supplies tendered or approves specific services rendered as partial or complete performance of the contract. It is the final determination whether or not a facility or system meets the specified technical and performance standards.

Access control Specifically computer systems access control. Restrictions on the

types of interactions between subjects (i.e., persons) and objects (i.e., files or data

elements). Access can be divided into types of access such as read, write, modify,

or execute. (Access control also includes physical access control.)

Acquisition Acquiring by contract with appropriated funds supplies or services by

and for the use of the federal government through purchase or lease, whether the

supplies or services are already in existence, or must be created, developed,

demonstrated, and evaluated. Acquisition begins at the point when agency needs are established and includes the description of requirements to satisfy agency needs,

solicitation and selection of sources, award of contract, contract financing, contract

performance, contract administration and those technical and management function

directly related to the process of fulfilling agency needs by contract. See also

procurement.

Accreditation A critical management decision made by an agency official regarding

the adequacy of security safeguards, i.e., whether the safeguards reduce risk to an

acceptable level for the intended function. It must be based on reliable technical

information. It is the approval to operate a computer system. See certification.

ADP Automatic data processing. ADP refers to the resources used to process

automated information, including telecommunications. The FIRMR now uses the

term Federal Information Processing (FIP) resources.

Administration Specifically contract administration. Government management of a

contract to ensure that the government receives the quality of products and services

specified in the contract within established costs and schedules.

Analysis of integrity, availability, and confidentiality requirements An analysis

of the protection requirements of a system based on the system's need for integrity,

availability, and/or confidentiality.

95
Analysis of level of assurance An analysis of the level of confidence needed that

the security of a system will work correctly and will be effective. This analysis

forms the basis for the procurement evaluation plan and/or acceptance plan.

Assurance A measure of confidence that the security features and architecture of a computer system meet the security requirements.

Authenticate To establish the validity of a claimed identity.

BAFO Best and Final Offer. An opportunity for offerors in the competitive range

to submit final proposals.

Bidder Any entity that responds to an invitation for bids with a bid. See offeror.

Benchmark A test of the capabilities of a proposed system using customized

workloads

Certification

1) Security certification A technical analysis of a system or application relative

to a set of system requirements used for the purpose of accreditation. See

accreditation.

2) Security certification A technical analysis and formal declaration by an agency official that an application or system meets all applicable federal

policies, regulations, and standards, and that safeguards are adequate for the

application.

3) Procurement certification A signed statement by an offeror.

Closeout Includes all final contract activities, e.g., ensuring completion of all requirements, making the final payment.

Commercial off-the-shelf (COTS) Software and hardware that already exists. It is

also referred to as off-the-shelf.

Competition in Contracting Act of 1984 (CICA) A statute that made several

revisions to federal contracting including requiring that specifications be developed in an "unrestricted manner" to obtain full and open competition.

Computer Security The protection of automatic data processing assets from harm.

This includes the protection of data, hardware, firmware, and software. Harm is defined as a loss of integrity, availability, or confidentiality.

Computer Security Act of 1987 A statute "to provide for a computer standards

program with the (National Institute of Standards and Technology), to provide for

96
government-wide computer security, and to provide for the training in security

matters of persons who are involved in the management, operation, and use of

federal computer systems, and for other purposes."

Confidential Private, nondisclosable. (In this guideline confidential never refers to

classified material.)

Contingency planning Plans to assure that users can continue to perform essential

functions and that a reasonable continuity of data processing support is provided at

all times. These plans can include emergency response, backup operation, and postdisaster recovery.

Contracting Officer (CO) A person with the authority to enter into, administer,

and/or terminate contracts and make related determination and findings.

Contracting Officer's Technical Representative (COTR) An individual to whom

the Contracting Officer delegates certain contract responsibilities, usually related to

technical direction and acceptance issues. Also called Government Technical

Representative (GTR) or the Contracting Officer's Representative (COR).

DAC See discretionary access control.

Delegation of Procurement Authority (DPA) A grant of authority by GSA to

acquire FTP resources or services. See section II.B.2.

Deliverable A product or service that is prepared for and delivered to the

government under the terms of a contract.

DES Data Encryption Standard. FIPS PUB 46-1. Specifies an algorithm to be

implemented for cryptographic protection of sensitive data.

Discretionary access control A means of restricting access to objects based on the

identity of subjects and/or groups to which they belong. The controls are discretionary in the sense that a subject with a certain access permission is capable

of passing that permission (perhaps indirectly) on to any other subject. See access

control and mandatory access control.

Directed specification A specification that must be included in statements of work

based on federal law, policy, or regulation.

Domain The unique context in which a program is operating.

97
Evaluation

1) Security evaluation The examination of the technical and nontechnical

security features of a computer system and other safeguards that establishes the

extent to which a particular design and implementation meet a specified set of

security requirements.

2) Procurement technical evaluation The examination of proposals in order to determine technical acceptability and merit. This is part of the source selection

process.

3) Product security evaluation The examination of the security features of a product against a stated set of requirements or criteria. Product evaluations are

often performed in a laboratory setting.

Federal Acquisition Regulation (FAR) The regulation that codifies uniform

acquisition policies and procedures for Executive agencies.

Federal Information Processing (FIP) FIP refers to the resources and services

used to process automated information, including telecommunications.

Federal Information Resources Management Regulation (FIRMR) The

regulation that sets forth uniform policies and procedures pertaining to acquisition of

information resources; used in conjunction with the FAR.

Features Specifically technical security features. The security-relevant functions,

mechanisms, and characteristics of system hardware, firmware, and software.

Technical security features are a subset of system security safeguards.

FIPS PUB Federal Information Processing Standards Publication

Flowdown The extension of prime contractor requirements to subcontractors.

Full and open competition The consideration of all responsible sources in a procurement, as required by the Competition in Contracting Act.

GSBCA General Services Board of Contract Appeals.

GTR Government Technical Representative. See Contracting Officer's Technical

Representative.

IFB Invitation for Bid. A solicitation document used when contracting by sealed

bids.

ITSEC Information Technology Security Evaluation Criteria. The harmonized

security criteria of France, Germany, the Netherlands and the United Kingdom.

98
IY&V Independent Verification and Validation.

Label

1) Security label A piece of information that tells a system how to handle data.

The label can be used to control access, specify protective measures, or indicate

handling restrictions required by a security policy.

2) Access control label A piece of information that represents the security level or sensitivity designation of data in an object or the access authorization of a

subject.

Latent defects Defects that exist at the time of acceptance but are not discoverable

by a reasonable inspection.

Liquidated damages Compensation to the government for damages that result from

the contractor failing to deliver supplies or perform services. (See FAR 12.2 and

52.212-4).

Live test demonstrations (LTDs) The demonstration of capability or period of

time during which a government user requires an offeror to perform certain user- witnessed activities. These can include one or more benchmark tests. These occur

prior to contract award.

MAC Message authentication code or mandatory access control.

Mandatory access control A means of restricting access to objects based on the

sensitivity (as represented by a label) of the information contained in the objects and

the formal authorization of subjects to access information of such sensitivity. In a mandatory access control environment, users cannot pass their access rights to others

without express concurrence of the access control authority. See access control and

discretionary access control.

Mandatory requirements Those contractual conditions and technical specifications

that are established by the government as being essential to meeting required needs.

Mechanism Specifically security mechanism. See safeguard.

Multi-label Having information with different sensitivities on one system. A multilabel secure system permits simultaneous access by users not authorized by the

mandatory access authority to access all of the data and prevents unauthorized

access. This term is normally used to describe systems with nonhierarchical

information sensitivities and where the system is relied upon to enforce a mandatory

policy. See label and multilevel.

99
Multilevel Having information with different sensitivities on one system. A

multilevel secure system permits simultaneous access by users not authorized by the

mandatory access authority to access all of the data and prevents unauthorized

access. This term is normally used to describe systems with hierarchical information

sensitivities and where the system is relied upon to enforce a mandatory policy. See

multi-label.

Needs determination An assessment, performed as part of initial system planning,

which looks at the needs of an agency that might be met through automation.

Object A passive entity that contains or receives information. Access to an object

implies access to the information it contains. Examples of objects are: records,

blocks, files, programs, video displays, printers, network nodes, etc.

Object reuse The removal of residual data from a system resource prior to

reassignment and reuse.

Off-the-shelf Software and hardware that already exists. It is also referred to as commercial off-the-shelf (COTS).

Offeror Any entity that responds to an RFP with a proposal. See bidder.

Orange Book See TCSEC.

Preaward survey An evaluation by a surveying activity of a prospective

contractor's capability to perform a proposed contract.

Presolicitation The period preceding release of a solicitation that includes

preparation of documentation required by federal regulations.

Procedure Specifically security procedure. A type of safeguard based on human

actions (as opposed to technical features). These can be referred to as administrative safeguards.

Procurement Includes all stages of the process of acquiring property or services,

beginning with the process for determining need for the property or services and

ending with contract completion and closeout.

Procurement initiator The key person who represents the program office in

formulating information resources requirements and managing presolicitation

activities. Also called program manager, sponsor. This person often becomes the

contracting officer's technical representative (COTR).

100
Program manager See procurement initiator.

Protest A written objection by an interested party to a solicitation for a proposed

contract for the acquisition of supplies or services or a written objection by an

interested party to a proposed award or the award of such a contract.

RFC Request for Comment. An announcement requesting industry comment on a proposed system or other acquisition.

RFI Request for Information. An announcement requesting information from

industry in regard to a planned acquisition and, in some cases, requesting corporate

capability information.

RFP Request for Proposals. A solicitation document used in negotiated

acquisitions to communicate government requirements and to solicit proposals.

RFQ Request for Quotation. A solicitation document used in negotiated

acquisitions to communicate government requirements and to solicit quotations.

Requirements analysis A part of the acquisition cycle in which the requirements

for a system are developed.

Responsible prospective contractor To be responsible, a prospective contractor

must meet the requirements of FAR 9.104-1 which include the ability to be able

perform the contract based on the financial, technical, organizational, ethical, and

legal position of the contractor.

Responsive prospective contractor To be responsive, a prospective contractor must

comply in all material respects with the solicitation.

Restrictive specification A detailed and precise description of an item(s) being

acquired that needlessly limits competition, e.g., "brand name" without the words "or

equal."

Risk analysis The process of examining assets, threats, and vulnerabilities in order

to determine cost-effective security controls.

Safeguard Any action, device, feature, mechanism, procedure, technique, or other

measure that reduces the vulnerability of or threat to a system. Also called controls

or countermeasures.

101
Sensitive information Any information which the loss, misuse, modification of, or unauthorized access to, could affect the national interest or the conduct of federal

programs, or the privacy to which individuals are entitled under Section 552a of

Title 5, U.S. Code, but that has not been specifically authorized under criteria

established by an Executive order or an act of Congress to be kept classified in the

interest of national defense or foreign policy.

Sensitivity assessment An initial assessment of the general sensitivity of an agency

function.

Single-label A subset of a multi-label system in which only one type of labeled

information is processed at a time. See label and multi-label.

Solicitation An official government request for bids/proposals often publicized in

the Commerce Business Daily.

Source selection The process of evaluating proposals and determining which offeror

will be selected for contract award.

SEB Source Evaluation Board. A board comprised of technical, contract,

information resources management, and other representatives whose primary function

is to evaluate proposals received in response to an RFP.

Specification A description of the technical requirements for a material, product, or

service. Specifications should state only the government's actual minimum needs

and be designed to promote full and open competition, with due regard for the

nature of the services to be acquired.

Sponsor See procurement initiator.

Statement of work (SOW) A statement of the technical specification in the RFP

that describes the work or system required by the government.

Subject An active entity, generally a person, process, or device that causes actions

such as the flow of information.

TCSEC Trusted Computer System Evaluation Criteria. DoD 5200.28-STD. The

Department of Defense security evaluation criteria. Also called the Orange Book.

Threat Any circumstance or event with the potential to cause harm to a system in

the form of destruction, disclosure, modification of data, and/or denial of service.

102
Trusted computing base (TCB) Specifically DoD 5200.28. The totality of

protection mechanisms within a computer system — including hardware, firmware,

and software — that are responsible for enforcing a security policy.

Vetting Specifically personnel vetting. The process of investigating personnel with

the intent to approve or disapprove access to government resources. The

investigations can range from minimal checks to full background investigations.

Also called personnel screening.

Vulnerability A weakness in system security procedures, system design,

implementation, internal controls, physical environment, etc.

Warner Amendment 10 USCA 2315. Excludes certain systems from the

requirements of Section 111 of the Federal Property and Administrative Services Act

of 1949 (40 USC 795), including automatic data processing equipment or services if the function, operation, or use of the equipment of services involves intelligence

activities, involves cryptographic activities related to national security, involves the

command and control of military forces, equipment that is an integral part of a weapon or weapons system, or is critical to the direct fulfillment of military or

intelligence missions except for equipment or services to be used for routine

administrative and business application (including payroll, finance, logistics, and

personnel management applications).

103

References

Appendix E

Acquisition of Information Resources: Overview Guide, U.S. General Services

Administration; January 1990.

Boehm, B. W., "Software Engineering." IEEE Transactions on Computers, C-25,

December, 1976.

Agencies Overlook Security Controls During Development, General Accounting

Office Report to the Chairman, Committee on Science, Spec, and technology, House

of Representative; May 1988; GAO/IMTEC-88-11 and GAO/IMTEC-88-11S.

Computer Security Act of 1987, Public Law 100-235.

Department of Defense Trusted Computer System Evaluation Criteria, Department of

Defense; December 1985; DOD 5200.28-STD.

Federal Acquisition Regulation, Department of Defense, General Services

Administration and National Aeronautics and Space Administration.

Federal ADP & Telecommunications Standards Index, General Services

Administration; April, 1991.

Federal Information Resources Management Regulation, General Services

Administration; 41 CFR 201.

Federal Personnel Manual, Chapters 731, 732, and 736, Office of Personnel

Management.

Frankel, S. ed. Guidance on Software Package Selection, National Bureau of

Standards (U.S.); November 1986; Special Publication 500-144.

Gilbert, Dennis, et al, Sample Statements of Work for Federal Computer Security

Services, National Institute of Standards and Technology; November 1991; NIST

Interagency Report 4749.

Gilbert, Irene, Guide for Selecting Automated Risk Analysis Tools, National Institute

of Standards and Technology; October 1989; Special Publication 500-174.

105
Glossary of Computer Security Terms, National Computer Security Center; October

1988; NCSC-TG-004.

Guidance to Federal Agencies on the Use of Trusted Systems Technology, National

Institute of Standards and Technology; July 1990; NCSL Bulletin.

Guideline for Computer Security Certification and Accreditation, National Bureau of

Standards (U.S.); September 1983; FIPS PUB 102.

Guidelines for Security of Computer Applications, National Bureau of Standards

(U.S.); June 1980; FIPS PUB 73.

Information Technology Security Evaluation Criteria, Herausgeber: Der

Bundesminister des Inner, Bonn, Mai 1990.

Kiely, John, Assuring the Integrity of Purchased Software, Computer Security

Institute 17th Annual Computer Security Conference; November 1990.

Model Framework for Management Control Over Automated Information Systems,

President's Council on Management Improvement and the President's Council on

Integrity and Efficiency; January 1988.

NASA Automated Information Security Handbook, National Aeronautics and Space

Administration; September 1990; NASA Handbook 2410.9.

Office of Management and Budget Circular A- 130, Management of Federal

Information Resources, December 1985.

Review of General Controls in Federal Computer Systems, President's Council on

Integrity and Efficiency; October 1988.

Ruthberg, Zella G et al, Guide to Auditing for Controls and Security: A System

Development Life Cycle Approach, National Bureau of Standards (U.S.); April 1988;

Special Publication 500-153.

Standard Security Label for the Government Open Systems Interconnection Profile,

National Institute of Standards and Technology; February 28, 1991; draft FIPS PUB.

Todd, Mary Ann and Constance Guitian, Computer Security Training Guidelines,

National Institute of Standards and Technology; November 1989; Special Publication

500-172.

106
U.S. Department of Energy Risk Assessment Methodology, National Institute of

Standards and Technology; May, 1990, Interagency Report 4325.

Wallace, Dolores R. and John C. Cherniavsky, Guide to Software Acceptance,

National Institute of Standards and Technology, April 1990; Special Publication

500-180.

Wallace, Dolores and Roger Fujii, Software Verification and Validation: Its Role in

Computer Assurance and Its Relationship with Software Product Management

Standards, National Institute of Standards and Technology; September 1989, Special

Publication 500-165.

* U.S. G. P.O.: 1992-311 -891: 60651 107

NIST-114A

(REV. 3-90) U.S. DEPARTMENT OF COMMERCE

NATIONAL INSTITUTE OF STANDARDS AND TECHNOLOGY

BIBLIOGRAPHIC DATA SHEET

1. PUBUCATION OR REPORT NUMBER

NIST/SP-800/4

2. PERFORMING ORGANIZATION REPORT NUMBER

3. PUBUCATION DATE March 1992

4. TITLE AND SUBTITLE Computer Security Considerations in Federal Procurements: A Guide for Procurement Initiators

Contracting Officers and Computer Security Officials

S. AUTHOR(S)

Barbara Guttman

5. PERFORMING ORGANIZATION (IF JOINT OR OTHER THAN NIST, SEE INSTRUCTIONS)

U.S. DEPARTMENT OF COMMERCE

NATIONAL INSTITUTE OF STANDARDS AND TECHNOLOGY

GAITHERSBURG, MD 20899

7. CONTRACT/GRANT NUMBER

8. TYPE OF REPORT AND PERIOD COVERED

Final

3. SPONSORING ORGANIZATION NAME AND COMPLETE ADDRESS (STREET, CITY, STATE, ZIP)

Same as item #6

10. SUPPLEMENTARY NOTES

11. ABSTRACT (A 200-WORD OR LESS FACTUAL SUMMARY OF MOST SIGNIFICANT INFORMATION. IF DOCUMENT INCLUDES A SIGNIFICANT BIBUOGRAPHY OR

LITERATURE SURVEY, MENTION IT HERE.)

This document is intended to help agencies select and aquire cost-effective computer

security by explaining how to include computer security requirements in federal

information processing (FIP) procurements. The guideline has three parts. The first

part is an introduction to the two disciplines of computer security and FIP procurement,

which provide sufficient knowledge to understand the legal, conceptual, and regulatory

underpinnings of the document.

The second part explains the integration of computer security into the FIP procurement

process. The guideline recommends that the following analyses be included in procurement documentation: sensitivity determination; analysis of integrity, availability,

and confidentiality requirements; analysis of level of assurance required; and a planning phase risk analysis.

The third part of the document includes specifications and contract language for specific

computer security features, assurances, and procedures that can be included in FIP

procurements.

2. KEY WORDS (6 TO 12 ENTRIES; ALPHABETICAL ORDER; CAPITAUZE ONLY PROPER NAMES; AND SEPARATE KEY WORDS BY SEMICOLONS)

acquisition; assurance; computer security; procurement; requirements analysis; risk

analysis; specifications

3. AVAILABILITY UNLIMITED FOR OFFICIAL DISTRIBUTION. DO NOT RELEASE TO NATIONAL TECHNICAL INFORMATION SERVICE (NTIS).

X

ORDER FROM SUPERINTENDENT OF DOCUMENTS, U.S. GOVERNMENT PRINTING OFFICE, WASHINGTON, DC 20402. ORDER FROM NATIONAL TECHNICAL INFORMATION SERVICE (NTIS), SPRINGFIELD, VA 22161.

14. NUMBER OF PRINTED PAGES

112

15. PRICE

LECTRONIC FORM

ANNOUNCEMENT OF NEW PUBLICATIONS ON

COMPUTER SECURITY

Superintendent of Documents

Government Printing Office

Washington, DC 20402

Dear Sir:

Please add my name to the announcement list of new publications to be issued in

the series: National Institute of Standards and Technology Special Publication 800-.

Name

Company

Address

City State Zip Code

(Notification key N-503)

IiJLLjm. Technical Publications

Periodical

Journal of Research of the National Institute of Standards and Technology— Reports NIST

research and development in those disciplines of the physical and engineering sciences in which

the Institute is active. These include physics, chemistry, engineering, mathematics, and computer

sciences.

Papers cover a broad range of subjects, with major emphasis on measurement methodology and

the basic technology underlying standardization. Also included from time to time are survey

articles on topics closely related to the Institute's technical and scientific programs. Issued six times a year.

Nonperiodicals

Monographs— Major contributions to the technical literature on various subjects related to the

Institute's scientific and technical activities. Handbooks— Recommended codes of engineering and industrial practice (including safety codes)

developed in cooperation with interested industries, professional organizations, and regulatory

bodies.

Special Publications — Include proceedings of conferences sponsored by NIST, NIST annual

reports, and other special publications appropriate to this grouping such as wall charts, pocket

cards, and bibliographies.

Applied Mathematics Series— Mathematical tables, manuals, and studies of special interest to

physicists, engineers, chemists, biologists, mathematicians, computer programmers, and others

engaged in scientific and technical work.

National Standard Reference Data Series— Provides quantitative data on the physical and chemical

properties of materials, compiled from the world's literature and critically evaluated. Developed

under a worldwide program coordinated by NIST under the authority of the National Standard

Data Act (Public Law 90-396). NOTE: The Journal of Physical and Chemical Reference Data

(JPCRD) is published bimonthly for NIST by the American Chemical Society (ACS) and the

American Institute of Physics (AIP). Subscriptions, reprints, and supplements are available from

ACS, 1155 Sixteenth St., NW., Washington, DC 20056.

Building Science Series — Disseminates technical information developed at the Institute on building

materials, components, systems, and whole structures. The series presents research results, test methods, and performance criteria related to the structural and environmental functions and the

durability and safety characteristics of building elements and systems.

Technical Notes— Studies or reports which are complete in themselves but restrictive in their treatment of a subject. Analogous to monographs but not so comprehensive in scope or definitive

in treatment of the subject area. Often serve as a vehicle for final reports of work performed at NIST under the sponsorship of other government agencies.

Voluntary Product Standards— Developed under procedures published by the Department of

Commerce in Part 10, Title 15, of the Code of Federal Regulations. The standards establish

nationally recognized requirements for products, and provide all concerned interests with a basis for common understanding of the characteristics of the products. NIST administers this program

as a supplement to the activities of the private sector standardizing organizations.

Consumer Information Series— Practical information, based on NIST research and experience,

covering areas of interest to the consumer. Easily understandable language and illustrations provide useful background knowledge for shopping in today's technological marketplace.

Order the above NIST publications from: Superintendent of Documents, Government Printing Office,

Washington, DC 20402.

Order the following NIST publications -FIPS and NISTIRs-from the National Technical Information

Service, Springfield, VA 22161.

Federal Information Processing Standards Publications (FIPS PUB)—Publications in this series

collectively constitute the Federal Information Processing Standards Register. The Register serves

as the official source of information in the Federal Government regarding standards issued by

NIST pursuant to the Federal Property and Administrative Services Act of 1949 as amended,

Public Law 89-306 (79 Stat. 1127), and as implemented by Executive Order 11717 (38 FR 12315,

dated May 11, 1973) and Part 6 of Title 15 CFR (Code of Federal Regulations).

NIST Interagency Reports (NISTTR)— A special series of interim or final reports on work

performed by NIST for outside sponsors (both government and non-government). In general,

initial distribution is handled by the sponsor; public distribution is by the National Technical

Information Service, Springfield, VA 22161, in paper copy or microfiche form.
g

Xio

T3

V

C

aJ v> 1*2 s § o e U 2_ o\

on 9S

O t»H eE

egO.

o» Q s OQ

C3 t-

_

"83

CQ2