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. TABLE OF CONTENTS Executive Summary iii Preface ix Working Group Participants & Contributors x I. Introduction 1 A. Requirement 1 B. Scope 1 C. Target Audience 2 D. Terminology 2 II. Background 5 A. Computer Security 5 A.1. Basic Computer Security Concepts 5 A.2. Basic Computer Security Practices 10 B. FIP Procurement 11 B.1. Basic Procurement Concepts 12 B.2. Basic FIP Procurement Practices 13 B.3. Procurement Cycle from the Procurement Initiator's Point of View 15 III. Incorporating Computer Security into the Procurement Cycle 19 A. Participants 19 B. Computer Security in the Procurement Cycle 20 B.1. Planning 20 B.1.a.Needs Determination 21 B.1.b.Requirements Analysis 22 B.1.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 Deliverables37 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.1. Identification and Authentication Specifications 64 J.2. Discretionary Access Control Specifications65 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 Modules71 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 Specifications76 J.9.b(1) Multi-Label Communications76 J.9.b(2) Single-Label Communications77 J.9.b(3) Labeling Output 77 J.10.Mandatory Access Control Specifications78 APPENDICES Appendix ATable of Contents for Federal Government Requests For Proposals (RFP) 79 Appendix BAssurance 83 Appendix CPlanning Phase Risk Analysis 91 Appendix DGlossary 95 Appendix EReferences 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 Components26 Figure 6 Computer Security in the Procurement Cycle 35 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. Working Group Participants and Contributors Ronald Brunner Ronald G. Brunner & Associates Grace Culver General Services Administration Donna Dodson National Institute of Standards & Technology Virgil Gibson Grumman Data Systems/National Security Agency Daniel Gambel Grumman Data Systems/National Security Agency E. Taylor Landrum Grumman Data Systems Gerald S. Lang Department of Veterans Affairs Victor Marshall Booz-Allen & Hamilton/National Aeronautics & Space Administration Gary Morris ANSER Gary Oran Federal Emergency Management Administration Nicholas Pantiuk Grumman Data Systems/National Security Agency Chiquita Phillips General Services Administration 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 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 II.A, 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. 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, NISTIR 4749, 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 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. 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.1. 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. 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 - 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. 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. Figure 2. Multidisciplinary Coordination. 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. 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: - 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.1. 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 - 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, 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. 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 (IFB) 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/Specifications/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. 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. PROCUREMENT CYCLE FROM THE PROCUREMENT INITIATOR'S POINT OF VIEW Planning �Solicitation�Source �Adminis- General �Procurement � 쿞election 퀃ration & 쿞pecific � � 쿎loseout �컴컴컴컴컴컴탠컴컴컴컴컴컵컴컴컴컴컴컴탠컴컴컴컴컴컵컴컴컴컴컴퀼 � � � � Strategic/ 쿝equirements쿞tatement 쿐valuation 쿔nspection & Tactical 쿌nalysis 쿽f Work 쿽f Proposals쿌cceptance Planning � � � � 쿌nalysis of 쿐valuation � 쿎OTR Needs 쿟echnical 쿛lan � 쿝esponsi- Determination쿌lternatives� � 쿫ilities � 쿝eview of � � 쿑easibility 쿞olicitation� � 쿞tudy � � � � � � � 쿎ost/Benefit� � � 쿌nalysis � � � � � � � 쿞oftware � � � 쿎onversion � � � 쿞tudy � � � � � � � 쿘arket � � � 쿞tudy � � � Figure 4. Procurement Cycle. 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 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.1. 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. B.1.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. B.1.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 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. As with other aspects of security, it is important to remember that the goal is cost-effective 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 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. Figure 5. Flow Model for Computer Security Components. B.1.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 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. 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 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 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 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. 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 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. 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." 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. 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.) 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 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. 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: 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. *************************************************************** 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. 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 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). 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 representative/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. 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. 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 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 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 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 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. 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. 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. 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. 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). 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 III, 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. 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.) 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 - 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. 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. 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. 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. 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.1. 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. 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 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, maintain, and protect from modification or unauthorized access or destruction an audit trail of accesses to the objects it protects. The audit data shall be protected so that read access to it is limited to those who are authorized. 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 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. J.4.a. Encryption If encryption of sensitive but unclassified information (e