AttachmentF_Contractor Guide.pdf

Uv Ut::I-'C::U .1I11t::lll UI nt::dllli dilU nUlllGll1 .,;),,"1 VI"""", Table of Contents

Table of Contents .......................................................................................... I Preface

Document Usage .........................................•...............•.....••......................... IV

Document Change History ..................................................•....................•..... v

1. Introduction ............................ :

1.1 Purpose

1.2 Background ............ ~ .................................................................... '

1.3 Scope

1.4 Document Organization ...... ;

2. Defining Contractor Systems and Related Security Requirements

2.1 CM Components and Responsibilities

2.1.1 System Security Plan (SSP)

2.1.2 Contingency Plan and Contingency Plan Testing

2.1.3 Baseline Security Requirements (BLSR)

2.1.4 Security Testing and Evaluation (ST&E)

2.1.5 Plans of Action and Milestones (POA&M)

2.1.6 Self Assessments

2.2 Document Review, Maintenance and Continuous Monitoring

3. Privacy Compli;;lnce .......................................... ,

3.1 System of Records Notice (SORN)

3.1.1 Contractor Respo·nsibilities

3.1.2 OPDIV Responsibilities

3.1.3 Suggested Contractual Language

3.2 Privacy Impact Assessment (PIA)

3.2.1 Contractor Responsibilities .................................. :

3.2.2 OPDIV Responsibilities

3.2.3 Suggested Contractual Language

3.3 Privacy Documentation

·3.3.1 Contractor. Responsibilities .................................... ;

3.3.2 OPDIV Responsibilities

3.3.3 Suggested Contractual Language .............. :

3.4 Chain of Trust Agreements

3.4.1 Contractor Responsibilities

3.4.2 OPDIV Responsibilities

3.4.3 Suggested Contractual Language

4. Delivery and Tracking of Contractor Training

4.1 Information Security Training ..................................................... ~

4.2 Compliance and Tracking

For Official Use Only 11/07/2006

Pagei

U0 Ut:parullt:m or neann ana nurnan "ervlces

5. Information Technology Contract Acquisition Solicitation and Contract Provisions ........................................................... ~ ....................................•.. 18

5.1· Information Security Pre-Solicitation Checklist and Certification

5.2 Information Security Solicitation Provision

5.3 Prospective Offeror Non-Disclosure Agreement

5.4 Information Security Pre-Award Checklist and Certification

5.5 Information Security Contract Provision

5.6 Access to HHS Electronic Mail Provision .......................... .-

5.7 Commitment to Protect Non-Public Information Contractor Agreement

5.8 Non-Personal Services and Inherently Government Functions Provision ... 20

5.9 Safeguarding ·of Sensitive but Unclassified Information Provisions

·5.10 FAR Clause 52.204-2, Security Requirements

5.11 FAR Clause 52.239-1, Privacy or Security Safeguards

Appendix A: Document Feedback Form Appendix B: References Appendix c: Acronyms ............................................................................•.. 24 Appendix D: Glossary ........•.•........•••.. ~ .......................•..........................• Appendix E: Information Security Pre-Solicitation Checklist and Certification Form ...........................................................................................• Appendix F: Information Security Solicitation Provision •••••••••••••••••••••••••••• 37 Appendix G: Prospective Offeror Non-Disclosure Agreement

. Appendix H: Information Security Pre-Award Checklist and Certification •• 47 Appendix I: Information Security Contract Provision Appendix 1: Access to HHS Electronic Mail Provision Appendix K: Commitment to Protect Non-Public Information Contractor Agreement ..................•.......••...........................••.•.............•......................•.. 59 Appendix L: Non-Personal Services and Inherently Government Functions Provision .................................................................• Appendix M: Confidential Treatment of Sensitive Information Provision •••• 61 Appendix N: Roles and Responsibilities for Section 2 Appendix 0: CISO Working Group CIlA SubcommitteeCIlA Checklist ••••••••• 64

For Official Use Only

Pageii

U.;) Ut:I..IClllIllt:11l VI nt:ClILII ClIIU nUlIiCll1 .;)t:1 VIl,O;:'

Preface

As the Department of Health and Human Services (HHS) Information Security Program evolves, this document will be subject to review and update, which will occur annually or when changes occur that signal the need to revise the HHS Contractor Oversight Guide. These changes may include the following:

• Changes in roles and responsibilities;

• Release of new executive, legislative, technical, or Departmental guidance;

• Identification of changes in governing policies;

• Changes in vulnerabilities, risks or threats; and/or

• HHS IG findings that stem from a security audit.

The HHS Chief Information Security Officer (CISO) must approve all revisions to the HHS Contractor Oversight Guide. Revisions are to be highlighted in the Document Change History table. Each revised guidance document is subject to HHS' document review and approval process before becoming final. When it is approved, a new version of the HHS Contractor Oversight Guide will be issued, and all affected parties will be informed of the changes made.

For Official Use Only

Page iii

U~ uepartment ot Healtn and Human ~ervlces

Document Usage

The procedures outlined in the Secure One HHS Contractor Oversight Guide are designed to provide guidance to the Department in meeting or exceeding the policies identified in the HHS Information Security Program Policy document and the requirements mandated by the Federal Information Security Management Act (FISMA). The Secure One HHS Contractor Oversight Guide provides specific guidance for the recommended implementation of a comprehensive contractor oversight capability. While the specifics of how to undertake the implementation are not mandatory, any alternative implementation undertaken by an Operating Division (OPDIV) must result in security controls and processes that are equal to or stronger than those articulated in the policies, handbooks, and related guides. If an OPDIV or Staff Division (STAFFDIV) chooses not to adopt the baseline guidance set forth in this Secure One HHS Contractor Oversight Guide, it must assume responsibility for the creation of procedures of equal or greater stringency.

While compliance with Federal directives (e.g., FISMA); Federal Information Processing Standards Publications (FIPS PUBS) issued by the National Institute of Standards and Technology (NIST) after approval by the Secretary of Commerce;

and, other Federal rules) and HHS directives (e.g., Information Security Program policies) are required, the adoption or tailoring of all other aspects of this guide -i.e., recommended business practices, processes, templates and provisions -- is left to the discretion of each OPDIV and StaffDIV.

NOTE: The Office of the Secretary, Assistant Secretary for Administration and Management, Office of Acquisition Management and Policy (OS-ASAM-OAMP) plans to develop formal acquisition policy for contracting officer that are responsible for ensuring that all information technology acquisitions comply with FISMA and the HHS Information Security Program Policy. This policy will be developed in consultation with the Executive Committee for Acquisition (ECA), the HHS Acquisition Regulation (HHSAR) Workgroup, and the Office of the Chief Information Officer (CIO). Where appropriate and in the event of a conflict, this guide will be updated to reflect formal information technology acquisition policy.

For Official Use Only

Page iv

US Department of Health and Human Services

Document Change History

1.0 08/14/2006

2.0 11/07/2006

For Official Use Only 11/07/2006

Initial OPDIV

Comments Final Document

Release

N/A

N/A

Secure One

HHS

Secure One

HHS

Page v

__ --t'-' ,1'1_, n VI I '_UI\.II UIIU I IUIIIQII ,",,'VI YIVv~

1. Introduction

The HHS is responsible for implementing and administering an information security program to protect its information resources, in compliance with applicable public laws, federal regulations, and Executive Orders, including the FISMA; the Office of Management and Budget (OMB) Circular A-130, Management of Federal Information Resources, dated November 28; 2000; and the Health Insurance Portability and Accountability Act of 1996 (HIPAA). To meet these requirements, the Department has instituted the HHS Information Security Program Policy document and accompanying HHS Information Security Program Handbook document.

The HHS Contractor Oversight Guide was created as part of the HHS Information Security Program to act as a guide for developing protocols and standards to assist with the security management of information stored, handled or processed by contractors and contractor systems.

1.1 Purpose

This guide provides the Department with standardized but adaptable Contractor Oversight direction that is in line with both Departmental and federal policies. This guide also includes new Information Technology (IT) regulations included in the Federal Acquisition Regulation (FAR) that apply to management of contractors and the subsequent security of federal information. These new regulations are strictly based on FISMA language and designed to facilitate the integration of IT Security throughout the contract lifecycle. This guide articulates information pertaining to recommended acquisition provisions for use by contracting officials, the security of contractor systems, privacy compliance, and the delivery of and tracking of contractor training.

1.2 Background

Section 3544(a)(1)(A)(ii)of FISMA describes federal agency security responsibilities as including "information systems used or operated by an agency or by a contractor of an agency or other organizations on behalf of an agency." Additionally, Section 3544 (b) requires each agency to provide information security for the information and "information systems that support the operations and assets of the agency, including those provided or managed by another agency, contractor, or other source."

Since FISMA applies to the information and information systems used by the agency, contractors, and other organizations, it has a more wide-ranging applicability than prior security laws. Types of organizations· may include, but are not limited to, contractors, grantees, State a.nd local governments, and industry partners. As a result, an agency IT security program encompasses not only those entities that directly possess or use federal information, but also those that operate, use, or have access to Federal information systems on behalf of a Federal agency. Agencies must

For Official Use Only

U~ uepanmem or Mealln ana Muman .;:,erVIt;e:;

develop policies for the information security oversight and review of contractors and other users with privileged access to Federal data.

FISMA applies to federal information, and in certain limited circumstances, its requirements also apply to a specific class of IT to which the Clinger-Cohen Act did not. Therefore, when Federal information is used within incicientally acquired equipment, the agency is responsible for ensuring FISMA requirements are met.

Increasingly, contractors are supplying, operating and accessing critical Federal IT systems and information.

1.3 Scope

This document applies to all Departmental personnel, which includes all OPDIV personnel and any contractor staff involved with the HHS contract acquisition process. Any staff members tasked with conducting contracting activities Should be granted access to this document to assist them in their understanding and integration of information security into their overall process.

1.4. Document Organization

The remainder of this guide is structured as follows:

• Section 2 defines contractor systems and related security requirements. This section also describes the management of Plan of Action and Milestone (POA&M) weaknesses and the certification and accreditation (C&A) of contractor systems.

• Section 3 describes the privacy requirements pertinent to contractor systems and information.

• Section 4 describes the delivery and tracking of contractor training.

• Section 5 describes contract acquisition language clauses and provisions.

This guide also contains the following appendices:

• Appendix A provides a feedback form for use in submitting comments on this document to HHS.

• Appendix B lists the references used in this document.

• Appendix C lists the acronyms used in this document.

• Appendix D defines terms most frequently used in this document.

• Appendix E provides the Information Security Pre-Solicitation Checklist and

Certification.

• Appendix F offers proposal assistance where Information Security is applicableto the solicitation.

• Appendix G provides the Prospective Offeror Non-Disclosure agreement.

• Appendix H provides the Information Security Pre-Award Checklist and

Certification.

For Official Use Only u;;;, uepanmerll UI nei::lIl1l ailU nUlllCli1 ~0::>1 v ,,,0::><>

• Appendix I explains the contract provision that is necessary to include in any " subcontract awarded by a contractor required to develop or access federal automated information changes.

• Appendix J offers contract language" assistance for contracts involving access to HHS Electronic Mail.

• Appen(jix K provides the Commitment to Protect Non-Public Information Contractor Agreement.

• Appendix L explains the contraCt provision regarding Non-Personal Services and Government Functions.

• Appendix M explains the contract provision regarding Confidential Treatment of Sensitive Information.

• Appendix N provides the roles and responsibilities from contract acquisition language clauses and provisions.

• Appendix 0 provides the CISO Working Group Certification and Accreditation (C&A) Subcommittee's C&A Checklist.

" For Official Use Only

US Department of Health ana Human ~ervlces

2. Defining Contractor Systems and Related Security Requirements

Information systems subject to Departmental and Federal requirements are predominantly maintained by Department personnel within HHS facilities; however, there exists a substantial number of contractor-run systems. This section is intended to clarify security requirements for these contractor-based systems as well as define the related roles of contractors and Departmental personnel.

The Department's C&A process remains the primary standard by which system security is evaluated. Consistent with Departmental requirements, security documentation to include the constituent parts of a C&A package must be maintained and reviewed for each system reported under FISMA. This includes contractor systems.

For the purposes of this section, a contractor system is defined as any general support system, major application or minor application hosted or maintained by contractor staff including information systems used or operated by a contractor of an agency or other organization on behalf of an agency1. This includes all systems physically or logically located within the boundaries of contractor facilities, including government and non-government entities, and systems which reside within HHS boundaries but the primary support for which is delivered by contractor staff;

Consistent with OMB Memorandum (M)-OS-lS, the Department retains all FISMA related security responsibilities - to include the security of systems - with respect to all contractor-based systems. According to OMB M-06-20, five primary categories of contractors as they relate to securing systems and information: 2

• Service Providers: This encompasses typical outsourcing of system or network operations, telecommunications services, or other managed services (including those provided by another agency).

• Contractor Support: This encompasses on or offsite contractor technical or other support staff.

• Government Owned, Contractor Operated (GOCO): For the purposes of FISMA, GOCO facilities are agency components and their security reqUirements are identical to those of the managing Federal agency in all respects. Security requirements must be included in the terms of the contract.

• Laboratories and Research Facilities: For the purposes of FISMA, laboratories and research facilities are agency components and their security reqUirements are identical to those of the managing Federal agency in all respects. Security requirements must be. included in the terms of the contractor or other similar agreement.

• Management and Operating Contracts: For the purposes of FISMA, management and operating contracts include contracts for the operation, 10MB M-05-15, FY 2005 Instructions for Preparing the Federal Information Security Management Act Report and Privacy Management Report, June 13, 2005.

20MB M-06-20, FY 2006 Reporting Instructions for the Federal Information Security Management Act and Agency Privacy Management, July 17, 2006.

For Official Use Only Page 4 maintenance, or support of a Government-owned or-controlled research, development~ special production, or testing establishment.

As required by FISMA, systems maintained in each of thesethree categories must be held to the same strict security standards as Department-owned systems. According to OMB M-06-20, "all information systems used or operated by an agency or by a contractor of an agency or other organization on behalf of an agency must be tested at least annually."

2.1 C&A Components and Responsibilities

National Institute of Standards and Technology (NIST) and Departmental guidance provide minimum documentation standards for C&A packages. C&A packages typically consist of the following:

• Risk Assessment

• SSP

• BLSR

• Contingency Plan and Contingency Plan Test Plan and Results

• ST&E Plan and Security Assessment Report

• POA&M

• Self-Assessment

• CM Letters

Table 1 provides a high-level view of the most common CM package components and the roles played by both Departmental and contractor personnel. For system Development and Implementation roles that have both the contractor and the federal entity field completed, either party could assume the initial responsibility for the developm~nt of the required documentation. For those roles where only the contractor is identified as the responsible party, it is recommended that a third-party assist in the completion of this requirement.

Each Departmental system varies in a numbet of ways - complexity, budget, supporting resources, and the physical and logical environments in which it is

For Official Use Only

PageS located. Most importantly, each system varies in its importance and/or potential risk to the mission of the organization, as indicated by its FIPS 199 categorization. This determination is made by Department officials and security stakeholders in their evaluation of the confidentiality, integrity and availability of the system. Such a determination may be made in consultation with contractor support staff, but the final deciSion reSides solely with the CISO or appointed staff. Further, it is the responsibility of Department staff to review system sensitivity and make changes to the FIPS 199 categorization when necessary. Each of these variables directly influences the level of effort, evaluative criteria, processes and resulting documentation required for C&A activities.

Contractors and Department staff play vital roles in the development of C&A packages; however the Department is ultimately accountable for the approval and effectiveness of e&A and, further, FISMA-related activities. M"06-20 states "that contractor, state, or grantee systems process, store, or house Federal government information (for which the agency continues to be responsible for maintaining control), their security controls must be assessed against the same NIST criteria and standards as if they were a government-owned or operated system."

Oversight of all C&A activities are non-transferable. Responsibility for the implementation of proper Department-compliant C&A processes and procedures and, . in turn, the production of required C&A package documents, continuous review and monitoring, testing and reaccredidation rests with the Department and OPDIV CISOs.

The suite ofNIST publications governing C&A activities prescribes a comprehensive set of roles, responsibilities, and activities. These have been compiled and reproduced in checklist format and included in Appendix N.

2.1.1 System Security Plan (SSP)

The assigned FIPS 199 risk impact level will determine the system's baseline security controls and the security control descriptions that comprise the majority of the information contained within the SSP.

Department personnel are responsible for the reView, approval, implementation and annual evaluation of the SSP. Certain duties may be assigned to contractors however Department personnel are solely responsible for the approval and oversight of all activities. Department officials must ensure plan components meet or exceed

. those prescribed by Departmental policies. Additionally, SSPs must remain accessible. As such, current copies of SSPs must be kept with the system and in the possession of the CISO or system owner, such as tile system owner.

For Official Use Only

-Figure 1. SSP Responsibilities

Department/OPDIV

Oversee SSP development activities

Review and approve SSP ;:It le1jstannupJlY

Ensure SSP and the securitY;C9ntr~lS it:

contains are prOperlyjmpletn~nte~·· .•

Maintain up-to-~ate'cciPi~S()i~~~Sf;r" reference

2.1.2 Contingency Plan and Contingency Plan Testing

Contingency planning requires a comprehensive knowledge of:

• Contingency planning requirements;

• Physical and logical system environments; and

• System contingencies and resdurces in the event of failure.

As such, contractor staff involved in the day-to-day system operations may possess unique insight and be most conversant with the information required to populate contingency plans. Contingency plan development by contractors, in cases such as these, is encouraged. Department personnel must oversee and validate contingency planning efforts and documentation. Department personnel, and ultimately the CISO, are responsible for ensuring documentation is consistent with Departmental policies and FISMA requirements, and the resulting contingency plans are fully implemented. Additionally, contingency plans must be tested on an annual basis. It is the responsibility of the CISO to ensure these tests are conducted, the results of which must be documented. Oversight of mitigation of weaknesses discovered through the contingency planning process remains the responsibility of the CISO;

In certain cases, a contractor may be contractually obligated to carry out some or all contingency planning requirements. Such agreements do not relieve Department personnel of oversight responsibility.

2.1.3 Baseline Security Requirements (BLSR)

The security baseline provides a snapshot of the security requirements which must be met to maintain compliance and identify IT security strengths and we,aknesses ..

The results of a security baseline analysis enable agency executives to evaluate their IT security posture and identify areas for improvement. Each system is unique. As such, it is expected that agencies incorporate application and platform-specific reqUirements into the BLSRs. These include industry-standard best-practices and manufacturer-recommended security standards. Tailored BLSRs ensure that security is adequately addressed.

For Official Use Only

Systems with a greater degree of overall sensitivity, or greater FIPS 199 risk impact level, require a more extensive set of minimum security requirements. Annexes 1, 2, and 3 of NIST Special Publication (SP) 800-53 identify recommended security controls for systems categorized as Low, Moderate or High, according to FIPS 199 categorization criteria. Each annex outlines mandatory management, operational, and technical security controls.

Department and contractor staff must work together to ensure appropriate baselines are chosen and additional controls are defined to augment the baseline where possible. Departmental stakeholders, however, remain ultimately responsible for ensuring proper baselines are determined and leveraged throughout the lifecycle of the system.

2.1.4 Security Testing and Evaluation (ST&E)

Systems reside in various physical and logical environments, process varying types of data and maintain specialized functions. Therefore, customized testing may be required to ensure security controls are operating adequately. Personnel with special insight into the system due to day-to-day interaction may prove vital to the security testing and evaluation process. This may, in some cases, include contractors. Such personnel may contribute to testing plans, but it must be noted that, for Moderate and High FIPS 199 systems, an independent certification agent or certification team should conduct the security certification ofthe information system3. Independent security certification services can be obtained from other elements within the organization or can be contracted to a public or private sector entity outside of the organization. Either the Department or contractors may be responsible for determining this independent party.

Findings resulting from the ST&E process are typically described in detail in the Security Assessment Report (SAR). Risks, impacts and potential risk mitigation activities are highlighted in this independent report. The SAR is a product of an independenttesting effort.

2.1.5 Plans of Action and Milestones (POA&M)

The POA&M is typically completed as a result of the ST&E process. The POA&M itself may be compiled by a contractor, however it is expected that input will also be provided by Department personnel responsible for the security of the system.

POA&M weaknesses require specific information which may not be readily available to contractors, such as estimated completion dates for required resources, weaknesses or milestones. According to M-06-20, system owners and, ultimately the OPDIV eISO, are responsible for the approval, management and oversight of weaknesses contained with a system's POA&M. While the efforts of contractors may contribute to the inclusion or completion of POA&Mitems, it remains a management tool maintained by Department personnel.

3 NIST SP 800-53, Revision 1 defines an independent certification agent or certification team as "any individual or group capable of conducting an impartial assessment of an organizational information system."

For Official Use Only Page 8

2.1.6 Self Assessments

NIST SP 800-26, Revision 1, provides an update to the self-assessment criteria consistent with NIST SP 800-53 and its annexes, and FIPS 199. The publication provides the template and content for both program and system level self assessment questionnaires which must be completed annually, based on FISMA requirements. FISMA requires that each assessment be conducted by the responsible agency. Contractor evaluation is, therefore, unacceptable. Each contract~r remains responsible for ensuring the overall system security however the ultimate responsibility for system self-assessment resides with the Department or

OPDIV.

2.2 Document Review, Maintenance and Continuous Monitoring

Federal regulations· and NIST guidance prescribe the regular review and maintenance of C&A-related documents .

. The Department, specifically OPDIV CISOs and apPointed staff, are responsible for ensuring system security controls and documentation is regularly assessed. In most cases, this must be done on an annual basis. Additionally, each CISO is responsible for the prompt re-accreditation of information systems. This must be accomplished at least every three years or as major changes are made to the system.

For Official Use Only

3. Privacy Compliance

The FAR requires that agenCies comply with privacy regulations as defined in the Privacy Act of 1974 and related OMB guidance .. Specifically, the Privacy Act mandates that contractors working with government agencies comply with the same privacy requirements as the agency. Pursuant to the FAR guidelines, the Department has also issued policy pertaining to privacy compliance and procedures related to the Privacy Act and subsequent OMB guidance, which should be applied to all contractors conducting business with HHS.

3.1 System of Records Notice (SORN)

The Privacy Act of 1974 is a code of fair information practices which regulates the federal branch collection, maintenance, lise, and dissemination of personally identifiable information.4 The Privacy Act also sets forth guidelines for filing and maintaining a SORN. A SORN is defined as a group of any records under the control of any agency from which information is retrieved by the name of the individual or by some identifying number, symbol, or other specific identifier assigned to the individuaJ.S Pursuant of the Privacy Act, all government contractors shall be considered employees of the government, and shall be subject to the requirements set forth in the Privacy AcL Systems that contain a Privacy Act System of Records (SOR) shall have a SORN created and filed in the Federal Register. Also systems

. that undergo a "major change" as defined in OMB M 03-22 (Attachment A(II)(B)(2» shall have an updated SORN.

3.1.1 Contractor Responsibilities

The Privacy Act requires contractors to complete and submit a SORN for publication in the Federal Register, and acquire a SOR number. In preparing a SORN for publication, contractors shall address specific system information detailed in the Privacy Act.6 Once published in the Federal Register,. SORN numbers shall be submitted to the appropriate agency contracting office, submitted to the agency Privacy Act Officer, and included in the associated system privacy impact assessment (PIA) (see Section 4.2).

3.1.2 OPDIV Responsibilities

OPDIVs are responsible for monitoring contractor compliance with all relevant poliCies outlined in the Privacy Act. Specifically, OPDIV contracting offices should include language in tlieir contracts that clearly articulates Privacy Act requirements and expectations for contractor compliance. Both the contractor(s) and the OPDIV

4 Privacy Act of 1974, found at http://www.usdoj.gov/04foia/04_7_1.htmJ.

5 5 U.S.C. § 552a(a)(5), Privacy Act of 1974.

65 U.S.c. § 552a(e)(4), Privacy Act of 1974. .

For Official Use Only

Privacy Act Officer to whom the contractor(s) will be reporting Privacy Act compliance should also be indicated in the contract.

3.1.3 Suggested Contractual Language

The following suggested language is for use in developing and maintaining contractual agreements with a contractor, pertinent to privacy SOR requirements:

"Contractor shall abide by all requirements of the Privacy Act of 1974.

Pursuant to those requirements, the contractor shall work with the OPDIV system owner or designee and the OPDIV Privacy Act Officer to publish a System of Record (SOR) notice in the Federal Register when a new System of Records is to be created and will publish an updated SOR notice following a "major change" as defined by Office of Management and Budget Memorandum 03-22 or subsequent replacement guidance."

3.2 Privacy Impact Assessment (PIA)

OMB M-03-22, OMB Guidance for Implementing the Privacy Provisions of the E-Government Act of 2002, "requires that all systems with a SOR notice published within the Federal Register conduct and review PIAs annually." In addition, Title II and III of the E-Government Act of 2002 require federal agencies to conduct PI As prior to developing or procuring IT systems that collect, maintain, or disseminate Information in Identifiable Form (IIF). Once completed, the Department's CIO, or an equivalent official, shall review the PIAs for completeness. Additional requirements include publishing the results of the PIA, if feasible, and posting a privacy notice, in machine-readable format, on all publicly facing government websites. Pursuant to the e-Government Act, Department policy requires all OPDIVs to complete and maintain a PIA for gll systems (e.g., developmental, operational, FISMA systems, and contractor-owned systems). In addition, systems that have been changed in such a way that they bear new privacy risks also require an updated PIA. Section 208 of the e-Government Act of 2002 describes a PIA as an analysis of how information (related to an SOR) is handled. The purpose of the PIA is to ensure privacy controls conform to applicable legal, regulatory, and policy requirements regarding privacy, to determine the risks and effects of collecting, maintaining and disseminating IIF in an electronic information system, and to examine and evaluate protections and alternative processes for handling information to mitigate potential privacy risks.

For Official Use Only

-----------. -'-'-'<:,1'-. -----

3.2.1 Contra"ctor Responsibilities

Contractors are required to work with OPDIV system owners to complete PIAs on all systems that will use, store, transmit, or process data owned by the OPDIV.

Contractors must also assist in creating initial PIAs for any new systems in development or operating within the Department. Upon completion, PIAs shall be submitted to the OPDIV contracting office and the OPDIV Senior Agency Official for Privacy or designee. In the event that a major change, as defined in OMB M-03-22, occurs to a contractor system, contractors are responsible for updating the system PIA to reflect the change. Contractors shall submit the updated PIA to the OPDIV contracting office and to the OPDIV Senior Agency Official for Privacy or designee.

3.2.2 OPDIV Responsibilities

OPDIVs are responsible for ensuring that PIAs and supporting documentation are completed according to the governing legislation and Departmental policy (e.g., Secure One HHS Information Security Program Policy). Specifically, OPDIVs shall grant contractors access to the ProSight tool to allow the contractor to complete and promote the PIA, or provide the HHS PIA template to the contractor and establish a point of contact for the contractor to submit the PIA. The OPDIVSenior Official for Privacy or designee must then promote the PIA via ProSight to the Department for review and public posting.

3.2.3 Suggested Contractual Language

The following language is suggested to OPDIVs for use in developing and maintaining contractual agreements with a contractor, related to the completion and review of PIAs:

"Contractor shall conduct and maintain an initial Privacy Impact Assessment (PIA) as defined by Section 208 of the E-Government Act of 2002. Periodic reviews shall be conducted by the system owner, with assistance from the contractor, to determine if a major change to the system has occurred, and if a PIA update is needed."

3.3 Privacy Documentation

Pursuant to FAR requirements, contractors shall create or provide system documentation that details the privacy controls implemented on each system that will use, store, transmit, or pass through data owned by the OPDIV.

For Official Use Only

3.3.1 Contractor Responsibilities

Documentation detailing privacy controls shall be updated by the contractor in the event that controls are not present on an existing system, or fail to meet established baseline privacy control requirements outlined in OPDIV system security plans and related documentation detailing privacy controls. Contractors may submit existing documentation to the agency for evaluation to ensure that contractor documentation adequately addresses privacy controls to protect data owned by the OPDIV.

3.3.2 OPDIV Responsibilities

OPDIVs shall require the contractor to submit system documentation detailing the implementation of privacy controls. OPDIVs shall evaluate contractor system documentation to verify that it adequately addresses privacy controls as found in the OPDIV'ssystem documentation. Finally, OPDIVs shall provide guidance to update or include privacy provisions in the system documentation if it does not meet the security and privacy documentation standards.

3.3.3 Suggested Contractual Language

The following language is suggested to OPDIVs for use in developing and maintaining contractual agreements with a contractor when system documentation must be reviewed:

"Contractor shall be responsible for preparing and maintaining current all documentation directly and indirectly relating to its program(s) designed to ensure the confidentiality, integrity, and availability of Federal Information and Federal Information System and its assets that enable its possession or control."

3.4 Chain of Trust Agreements

Pursuant to FAR language, contractors shall maintain chain of trust agreements for any other contracting entities that the contractor shall. employ.

3.4.1 Contractor Responsibilities

The contractor shall establish chain of trust agreements with any and all subcontractors it shall employ. Contractors shall require any subcontracting agency to comply with the same legislC!tive, regulatory, and Department guidance as set forth in the primary contractual agreement between the contractor and the OPDIV.

The contractor shall identify the subcontractor to the OPDIV contracting office.

For Official Use Only

3.4.2 OPDIV Responsibilities

OPDIVs shall provide a clear statement detailing chain of trust agreements in contractual language with any contractor in writing. Chain of trust agreements shall be provided and agreed upon by the contractor and the OPDIV. The OPDIV contracting office shall keep record of any subcontractor the contractor performs work with and shall ensure that chain of trust agreements are in place.

3.4.3 Suggested Contractual Language

The following language is suggested to OPDIVs for use in developing and maintaining contractual agreements with a contractor regarding chain of trust agreements:

"The cOntractor shall inform its workforce (employees and subcontractors it retains for staff augmentation purposes) of the sensitive non-public nature of Federal Information and shall limit access to workforce members and subcontractors basedon need to know principles. These principles shall be based upon theories of least privileges and minimum necessary, as set out in current NIST Publications. Additionally, the contractor shall require its subcontractors to comply with the same legislation, regulations, related guidance, and the objectives of the OPDIV and the Department (including the terms and conditions set forth in this agreemeAt) regarding the protection of Federal Information and Federal Information Systems."

For Official Use Only

4. Delivery and Tracking of Contractor Training

4.1 Information Security Training

It is required that contractors receive security training commensurate with their roles/responsibilities for performing work under the terms and conditions of their contractual agreements. According to M-06-20, each contractor employee must complete Security Awareness Training as required by the OPDIV prior to full system access, and on an annual basis thereafter, during the period of performance of the contract.

The Office of Personnel Management (OPM) has issued a policy (5 CFR 930) regarding information systems security awareness training programs. It directs each agency to develop a plan for federal information systems security awareness training, to identify employees or contractors with significant information security responsibilities and to provide role-specific training in accordance with NIST standards and guidance. 'OPM designates five significant security roles:

• All Users

• Executives

• Program and functional managers

• CIOs, IT security program managers, auditors, and .other security-oriented personnel .

• IT function management and operations personnel

OPM has dictated that employees/contractors who use or manage federal information systems must participate in various types of security training dependent upon their particular security roles within an agency. The designated OPM significant security roles and the corresponding required training for those roles are listed below.

Table 2. OPM Significant Security Responsibilities OPM Significant Security

Responsibility Role A. All Users (employees, contractors, students, guest researchers, visitors, others with access to federal systems) B. Executives

C. Program and Functional Managers

For Official Use Only 11/07/2006

Must Receive Training In These Areas

Exposed to security awareness materials annually

Information security basics, policy level training in security planning and management Information security basics, management and implementation level training in security planning and system/application security management; system/application life cycle management, risk management, contingency planning

OPM Significant Security Must Receive Training In These Areas Responsibility Role

D. CIO, IT Security Program Managers, Auditors, Other security-oriented personnel (system and network administrators, system/ application security officers)

E. IT Function Management and Operations Personnel

Information security basics, broad training in security planning, system and application security management, system/application life cycle management, risk management, contingency planning Information security basics, management and implementation level training in .

security planning and system/application security management; system/application life cycle management, risk management, and contingency planning

Alternative groupings of personnel with significant security responsibilities are possible. The OPDIV shall maintain a listing of all employees and contractors who have completed security awareness and role based training and shall submit this listing as part of the reporting process for annual FISMA compliance

4.2 Compliance and Tracking

In order to comply with federal directives and mandates, OPDIVs must implement a training program that relates to the security education of its employees/contractors and is capable of being tracked for FISMA compliance. Each OPDIV is responsible for the training of its contractors. The goal should be 100% compliance, whenever possible. Compliance reporting as outlined in M-05-15 includes the following data:

• Total number of employees

• Number and percentage of employees that received IT security awareness training as described in NIST SP 800-50

• Total number of employees withsignificant security responsibilities.

• Number and percentage of employees with significant security responsibilities that received specialized training as described in NIST SP 800-16

• Total costs for providing IT security training

• A brief description of the training provide

• Whether the agency explains poliCies regarding peer-to-peer file sharing in IT security awareness training, ethics training, or any other agency wide training

Once the agency determines how training will be implemented, it can then determine a method for monitoring the training. The training must be monitored so that it can accurately be recorded or "tracked" as proof of compliance with the OPM regulations (5 CFR 930) and FISMA. The OPDIV can conduct trackingin a number of ways, such as through manual means (e.g., attendance records), automatically by a Learning Management System (LMS), written or electronic agreement, or other methods.

Regardless of the method that the OPDIV uses to track the training, core information about each training session should be maintained. The Table 3, Tracking Information, displays an example of information to be tracked and the reason for tracking.

For Official Use Only

""......, LJ"tJQ""lvln. VI IlveUUI ailU I~UIIIClII vtiIVI\"C;"

Table 3. Tracking Information

Tracking Item Reason for Tracking

Employee Name Identify who took the training

Employee Number or Other ID # Verify who took the training HHS OPDIV Identify where employee is employed

Significant Security Role/Position Determine employee's security role

Current Certifications (e.g, CISSP, CISM, Capture education efforts in support of CISA) and date of completion employee's certifications and determine need for additional training Specific Course Completed Determine what topics are covered

In addition to tracking this information, the OPDIV must ensure that it is accessible to appropriate individuals when needed, in the form of a report. The report must allow management to gather any of the above data regarding completed security training. The OPDIV's tracking system should update all information periodically.

This system will ensure that all local and federal requirements for training contractor employees with significant security responsibilities can be monitored and implemented.

Additional security training requirements commensurate with the position may be required as defined in NIST SP 800-16, Information Technology Security Training Requirements (http://csrc.nist.gov Ipublications/nistpubs/800-16/800-16.pdf).

For Official Use Only

5. Information Technology Contract Acquisition Solicitation and Contract Provisions

Until recently, regulations related to the security requirements of contractors and their systems have been outdated. ·Effective November 30, 2005, the Civilian Agency Acquisition Regulations Council and the Defense Acquisition Regulation Council agreed upon a ruHng to amend the FAR. This new ruling mandated that the provisions of FISMA be incorporated into all federal agencies contracts and increased the responsibility of contracting officials to implement information security into the lifecycle of all contracts. The primary purpose of this new FAR language was to further emphasize and enforce the FISMA security requirements placed on all Federal agencies. According to M-06-20, The FAR, subpart 7.1 - Acquisition Plans, requires heads of agencies to ensure agency planners on information technology acquisitions comply with the information technology security requirements in FISMA, Appendix III of OMB Circular A-130, and guidance and standards from NISTJ Consequently, the communication between the Federal acquisition offices, IT security offiCials, and the Chief Information Officers (CIOs) should increase and/or improve. A summary of the five major amendments to the FAR include t.he following areas:

• Seeking advice from specialists in information security when buying goods and services

• Including a standardized definition for the term "Information Security" in contracts

• Incorporating security requirements in acquisition planning and when describing agency needs

• Requiring adherence to Federal Information Processing Standards (FIPS)

• Revising the policy in FAR 39.101 to require the inclusion of the appropriate agency security policy and requirements in information technology acquisitions

Essentially, these new regulations hold contractors accountable to the same conventions and security standards as federal employees when accessing and utilizing· Federal Information systems.

The following sections describe the content of checklists, forms and/or templates provided to assist contracting officials in the incorporation of security into all acquisition documentation, as appropriate. The actual checklists, forms and/or templates are included as appendices to this document.

5.1 Information Security Pre-Solicitation Checklist and

Certification

The Information Security Pre-Solicitation Checklist and Certification form (See Appendix E) is to be included in acquisitions when contractor personnel will deverop

. 70MB M-06-20, FY 2006 Reporting Instructions for the Federal Information Security Management Act and Agency privacy Management, July 17, 2006.

For Official Use Only or access federal automated information systems please refer to the HHS Information Security Program Policy and HHS Information Security Program Handbook located on the HHS Intranet (intranet.hhs.gov/infosec/docsl).

NOTE: Security Information relevant to the Request for Proposal (RFP) must be inserted through the document. The Project Officer (PO) and the Chief Information Security Officer (CISO) will assist in identifying this information.

5.2 Information Security Solicitation Provision

This section is inCluded to provide assistance in proposal preparation and is applicable to a solicitation involving information security (See Appendix F).

5.3 Prospective Offeror Non-Disclosure Agreement

A Non-Disclosure Agreement is necessary for a prospective offeror who will require access to federal information in order toprepare an offer (i.e., a prospective offeror must access an HHS computer room floor plan). (See Appendix F, for instructions;

See Appendix G for Non-Disclosure Agreement form)

NOTE: If this paragraph is not applicable to the RFP, delete it in its entirety.

5.4 Information Security Pre-Award Checklist and Certification

The Information Security Pre-Award Checklist and Certification form (See Appendix H) is to be included In acquisitions when contractor personnel will develop or access federal automated information systems. Please refer to the HHS Information Security Program PO.licy and HHS Information Security Program Handbook located on the HHS Intranet (intranet.hhs.gov/infosec/docsl).

NOTE: Security Information relevant to the Request for Proposal (RFP) must be inserted through the document. The Project Officer (PO) and the Chief Information Security Officer (CISO) will assist in identifying this information.

5.5 Information Security Contract Provision

Use the information within this section when contractor personnel will develop or access federal automated information systems (See Appendix I). For more information about information security please reference HHS Information Security Program Policy and HHS Information Security Program Handbook located on the HHS Intranet (intranet.hhs.gov/infosec/docsl).

For Official Use Only

- u.:> ueparrmem or neann ana nurnan ~ervlces .

5.6 Access to HHS Electronic Mail Provision

This language, as contained in the Appendix J form, is for use in contracts that will develop, purchase, maintain, or use electronic and information technology (EIT), unless these EIT products and/or services are incidental to the project.

NOTE: Other exceptions to this requirement can be found at FAR 39.204.

It is also for use in all acquisitions of energy-using products or services (including design, construction, renovation…