SOW.pdf

Statement of Work (SOW) FDA Cloud Interconnect Services and Support

July 190, 2019

1 Background The Office of Information Management and Technology (OIMT) mission is to provide the infrastructure, technologies, expertise, and services that enhance, transform, and sustain the ability of the FDA to protect and promote the public health. One of the primary methods by which it addresses these responsibilities is through promoting and enabling innovative technology‐based solutions, such as cloud and high‐performance computing.

In support of the Federal Chief Information Officer’s (CIO) “25‐point Implementation Plan to Reform

Federal IT”, Federal Data Center Consolidation Initiative (FDCCI) and the Office Management and

Budget’s (OMB) Cloud Smart Strategy and Federal Risk and Authorization Management Program

(FedRAMP), the FDA is expanding and modernizing its cloud computing infrastructure to align and meet the requirements of customer use cases across the Centers. The use cases include:

Achieving a compliant Federal Information Security Modernization Act (FISMA) authorization for AWS GovCloud supporting data categorized as low, moderate, and high.

Increasing network bandwidth that enables the migration of large applications and the transfer of large data sets from the FDA network to the cloud service providers (CSP) in near real‐time.

To achieve these requirements, OIMT is establishing this contract to acquire secure, high‐speed direct connections from the FDA to the Cloud Service Providers (CSPs) via of an Interconnect Service Provider

(ICSP), also known as Direct Connect. The interconnection is a secure private data exchange platform or hub between the FDA and CSPs. The FDA will connect to the ICSP, and the ICSP will provide the connections and services to the CSPs using high speed secure private direct lines. This is beneficial to the FDA since it only needs to manage the connections to the ICSP and does not need to acquire, implement, and manage individual connections to each CSP. The ICSP shall be cloud agnostic and able to provision on‐demand connections to FDA CSPs. Some of the FDA CSPs that are authorized to operate include Amazon Web Services (AWS), AWS GovCloud, Microsoft Azure, Microsoft Office 365, Appian, Salesforce, ServiceNow, and Box. Future FDA CSP offerings may include but not limited to Google Cloud and Oracle Cloud. In this contract, the ICSP vendor shall only provide connections to AWS GovCloud US‐

East (Ohio), AWS GovCloud US‐West (Oregon), and AWS US East (Northern Virginia). Connectivity from the ICSP to other FDA CSPs will be acquired via future contracts.

2 Objectives The objective of this contract is to acquire secure, high‐speed direct connections from the FDA to the

CSPs via of an ICSP. The acquisition will include the network circuits that connect FDA data centers to the Interconnect Service Provider data centers, Interconnect Service, technical support, and professional services to install, configure, test, and deploy the Interconnect Service to production. The FDA data centers include Ashburn Data Center (ADC) and White Oak Data Center (WODC). This contract will enable FDA to:

Fulfill security controls for the AWS GovCloud to operate under FISMA high categorization;

FISMA high categorization requires high availability (HA), and HA is one of the benefits of the

Interconnect Service.

Increase network performance and reduce latency issues between the FDA network and CSPs;

the Interconnect Service enables real‐time access to cloud resources and services

Provide increase network bandwidth needed to migrate large applications and to transfer large data sets from FDA on‐premise data centers to the cloud in high speed

Provide secure connections to the CSPs which comply with all Federal cloud computing regulations and security standards that are specified in Section 3.1; improve security by by‐ passing the public internet with a direct connection to the CSPs

Support the monitoring and inspection of cloud traffic between the FDA network and the CSPs

Increase communication reliability since faster data transfers with high‐speed connections are less vulnerable to system timeouts.

Facilitate Disaster Recovery (DR) with high speed direct and simultaneous connections to multiple CSPs that are geographically distributed across the Continental United States (CONUS)

Minimize resources required to acquire, implement, and manage individual connections from the FDA to each CSP

Extend the FDA network infrastructure footprint with greater reach and flexibility to manage network resources in the ICSP infrastructure facilities/data centers

Increase security and performance through direct connections that are more secure and reliable, and have lower latency than public internet connections

Provide on‐demand provisioning of connections to multiple CSPs

3 Requirements The vendor’s services and support shall meet the following requirements:

3.1 Interconnect Service Requirements

The ICSP shall provide and install two (2) network circuits from FDA data centers to the ICSP data centers that shall be 10Gbps Ethernet Private Line (EPL) connections. The first circuit shall originate from the FDA Ashburn Data Center (ADC) and terminate at one of the main ICSP data centers that is near ADC. An acceptable alternative to Ethernet Private Line EPL for this circuit at ADC is Inter Data Center leased fiber paths (dark fiber) in Ashburn and would be preferable if more cost effective. Quoters are encouraged to price and offer both options. The second circuit shall originate from the FDA White Oak Data Center (WODC) and terminate at a different ICSP data center. For this circuit, Quoters are also encouraged to price and offer both EPL and dark fiber options.

The ICSP infrastructure facilities/data centers shall comply with the following security standards:

FISMA high, NIST 800/53, SOC 1 Type II, SOC 2 Type II, ISO 27001, HIPAA, and PCI DSS.

The ICSP shall allow Network Layer 2 Ethernet connectivity from the FDA’s Data Centers (White

Oak Data Center (WODC) and Ashburn Data Center (ADC)) to the ICSP Data Centers.

The ICSP shall be a cloud agnostic and able to provision on‐demand connections to the following

CSPs: Amazon Web Services (AWS), AWS GovCloud, Microsoft Azure, Microsoft Azure

Government Cloud, Microsoft Office 365, ServiceNow, Salesforce, Box, Oracle Cloud, and Google

Cloud.

The ICSP infrastructure shall support fault tolerant operations across cloud environments and

FDA’s Data Centers (WODC and ADC). In case of system failure in one CSP/Data Center, the system shall support failover to the second CSP/Data Center.

The ICSP shall support HA by allowing two (2) redundant 10 Gbps uplinks uplink connections from FDA Data Centers (ADC and WODC) to the ICSP’s infrastructure.

The ICSP shall support HA by allowing FDA network equipment (i.e., routers, switches) to be installed across different Data Centers in the event one of the data centers has an outage.

The ICSP shall provide a high‐speed Network Layer 2 Ethernet connection between the FDA and their data center that is scalable to a minimum of 10Gbps.

The network bandwidth connections between the ICSP and CSP shall be a scalable up to a minimum of 10Gbps.

The ICSP shall allow FDA furnished network equipment (i.e., routers, switches) to be installed/hosted in their facilities for connectivity to the CSPs.

The ICSP infrastructure shall be compatible and able to integrate with FDA network equipment that will be hosted/installed in their facilities. The network equipment includes Cisco ASR 1000 series routers and/or Cisco Catalyst switches.

The ICSP shall secure FDA network routers and switches in a secure cabinet, rack, or cage to provide an additional physical security layer to prevent unauthorized access

ICSP data centers, infrastructure, technologies, circuits, and services shall have an average minimum uptime of 99.999%

The ICSP shall have multiple Data Center access locations distributed across CONUS with the

FDA connecting to a data center that is close to ADC and WODC in Washington DC metropolitan area.

All ICSP data centers, connections, and operations utilized by the FDA shall be within CONUS.

The ICSP vendor shall not impose a limit (data cap) on the amount of data transferred at a specified level of throughput over a given time period or throttle the data transfer rate.

The ICSP shall allow multiple layers of encryption to meet Federal guidelines for secure data communications.

Ethernet Private Line (EPL) Circuits shall support:

o QinQ Trunking (802.1ad) o Jumbo Frame Support

The ICSP shall provide on‐demand provisioning of connections to new CSPs

The ICSP solution shall allow the flexibility for the FDA to use or switch to the previous communication method to connect to CSPs through VPN connections that are Trusted Internet

Connection (TIC) compliant, providing an alternate and backup solution.

3.2 Support Requirements

1. The ICSP shall provide technical and logistical support 24 hours a day, 7 days a week, 365 days a year via phone, email, and internet with a 1‐hour response time.

2. The ICSP shall allow an unlimited number of incidents tickets to be submitted to resolve/troubleshoot issues and to provide technical support and guidance.

3. The ICSP shall not restrict the number of FDA staff named as authorized contacts to initiate support calls.

4. The ICSP shall not restrict the number of FDA staff named to have physical access to the government furnished equipment installed in secured enclosure.

5. The ICSP shall perform all technology upgrades, maintenance releases, patches, and bug fixes on their infrastructure facilities/data centers to comply with Federal and FDA technology and security standards as specified in Section 3.1.

6. The ICSP shall provide the capability to obtain reports or data on network bandwidth capacity utilization and consumption. The vendor shall be able to breakout the utilization and consumption data by CSPs and IP addresses for FDA cost allocation and chargeback purposes.

7.6. The ICSP shall provide access to on‐line technical documentation and self‐help resources such as knowledge bases and analysis tools.

4 Tasks This section defines the tasks that the vendor shall complete during contract performance. The vendor shall provide consulting services to the FDA to ensure the ICSP solution is optimally designed and implemented to meet the requirements specified in this SOW. The ISCP solution needs to be quickly setup, configured, and integrated with the FDA infrastructure in a timely and expert manner with no disruptions to existing systems or security compromises. The ICSP vendor shall ensure their expert knowledge is successfully transferred to FDA IT personnel that will be providing design, implementation, and operational support. Furthermore, the ICSP vendor shall provide on‐site access to FDA engineers and consultants with expertise on network equipment (i.e., routers) to be installed in the ICSP vendor facility/data center.

The vendor shall provide IT professional personnel to support OIMT on the following tasks:

4.1 Planning, Requirements, and Design Task

4.2 Installation, Configuration, and Maintenance Task

4.3 Testing, Troubleshooting, and Validation Task

4.4 Providing Interconnect Services and Support Task

The personnel working on the tasks shall be Subject Matter Expert(s) (SME) with hands‐on experience in designing and implementing ICSP solutions for Federal agencies and private businesses including security specific requirements (e.g. FIPS, FISMA etc.). They should also have certification to implement and maintain the infrastructure and technologies of their Interconnect Service. The SMEs shall be proficient and qualified with the latest versions of hardware and software that will be deployed in the

ICSP facility/data center. At the completion of the consulting services, the acquired software and hardware shall seamlessly integrate with the existing FDA system.

4.1 Planning, Requirements, and Design Task

The ICSP vendor shall perform the following activities in support of the Planning, Requirements, and

Design Task:

Review, analyze, and provide input and recommendations on the FDA requirements and overall cloud strategy of the interconnect solution

Review architecture design to ensure architecture/solution optimally meets the requirements and integrates with FDA provided equipment and network infrastructure

Ensure the design is scalable and expandable to meet future requirements to add new FDA approved CSPs

Review desired deployment end state, identify risks and deployment requirements, best practices for target CSPs, and create a custom next steps plan

Provide a checklist of items that need to be completed by FDA, and review and assist FDA staff to complete

Work with FDA network engineers to document and deliver the architect design/diagram that includes:

o Hardware/software components (servers, routers, switches) including model number/version o Connections from the FDA to the ICSP including network bandwidth and protocols o Connections from the ISCP to the CSPs including network bandwidth and protocols o Firewalls, IP addresses, ports, and Role Based Access Controls (RBAC) o Redundant components for HA o Connection and integration with external systems

4.2 Installation, Configuration, and Maintenance Task

The ICSP vendor shall provide technical assistance at the ICSP sites in support of the Installation, Configuration, and Maintenance Task:

Confirm completion of all prerequisites that need to be performed by the FDA. The prerequisites include ensuring FDA provided equipment and relevant CSP subscriptions have been procured and available, providing an edge network topology, providing remote access for the ICSP engineers to validate settings on the router equipment, and finishing the ICSP checklist to ensure readiness.

Provide and implement two (2) network circuits from FDA data centers to the ICSP data centers that shall be 10Gbps ethernet private line connections. The first circuit shall originate from the

FDA Ashburn Data Center (ADC) and terminate at one of the main ICSP data centers that is near

ADC. The second circuit shall originate from the FDA White Oak Data Center (WODC) and terminate at a different ICSP data center. The following are the addresses of ADC and WODC where the circuits shall originate:

o FDA White Oak Data Center (WODC)

10903 New Hampshire Avenue, Silver Spring, MD 20903 o FDA Ashburn Data Center (ADC)

44480 Hastings Drive, Ashburn, VA 20147

Provide and implement connectivity from the demarcation points of the circuits to the ICSP network.

Unpack FDA equipment from boxes that includes new and replacement equipment. Equipment includes but not limited to routers, interface cards, storage, and memory.

Install FDA equipment in secure cages at the ICSP facilities/data centers. This includes racking equipment and performing cabling/wiring activities.

Assemble, install, and maintain cabling/circuits to connect FDA equipment to ICSP network and panels

Track and report inventory of FDA equipment that includes recording the equipment model and serial numbers

Perform configurations between the FDA provided edge equipment and a single CSP

Transfer technical knowledge to FDA engineers to successfully manage and perform configurations between the FDA provided edge equipment and remaining CSPs

Provide access and technical assistance to FDA staff and consultants performing work at ICSP facilities/data centers

Provide support to run power cycles (reboot) on FDA provided equipment as necessary

4.3 Testing, Troubleshooting, and Validation Task

The ICSP vendor shall perform the following activities in support of the Testing, Troubleshooting, and

Validation Task:

Test circuits to ensure connection meets network bandwidth performance and reliability specifications

Work with FDA network engineers to perform end‐to‐end connectivity testing to verify operability from the FDA data centers to the CSP

Conduct testing of peering metrics (i.e., RDP, Ping and Traceroute, and file transfers) to an accessible service such as AWS S3

Conduct route table examination on FDA provided edge equipment and the CSP to verify expected routes

Perform troubleshooting that includes problem identification and resolution during the pilot and production rollout

Provide content and recommendations for troubleshooting guides for FDA operational support technicians.

Track and resolve issues encountered during the pilot and provide rollout support

Validate that all components and connections in the ICSP solution are operating in accordance with the requirements

Coordinate and provide support, guidance, and instructions in the pilot of the Interconnect

Service

Coordinate and provide support, guidance, and instructions in the Production deployment (Go

Live) of the Interconnect Service

Schedule and host a post‐deployment quality assurance call and perform knowledge transfer

4.4 Providing Interconnect Services and Support Task

The Providing Interconnect Services and Support Task shall occur in Base Year after the Production deployment (Go Live) and during Option Years 1 through 4. The ICSP vendor shall provide the following in support of this task:

Provide and support secure high‐speed direct connections in production from the FDA to the

CSPs (AWS GovCloud and AWS Commercial Cloud) via the interconnect service

Perform technology upgrades, maintenance releases, patches, and bug fixes on their infrastructure facilities/data centers to comply with Federal and FDA technology and security standards

Ensure ICSP data centers, infrastructure, technologies, circuits, and services have an average minimum uptime of 99.999%.

Replace and remove FDA equipment and equipment parts that are not functioning, have reached end of life support, need to be upgraded, or under the discretion and direction of FDA

Provide technical and logistical support as specified in Section 3.2

5 Project Milestones/Completion Dates The vendor shall plan to meet the project milestones/completion dates specified in the following table.

If the vendor cannot meet the milestone completion dates, the vendor shall immediately notify the COR of the reason for the delay and provide a proposed corrective action plan within one (1) business day.

Base Year

Sections Milestones Projected Completion Date

4.1, 4.2, 4.3 Kickoff Meeting Within 7 days of contract award

4.1 Requirements review meeting 1 day after Kickoff Meeting

4.1 Complete updated requirements 3 days after Kickoff Meeting

4.1 Architecture design and review working session

4 days after Kickoff Meeting

4.1 Complete architecture design 7 days after Kickoff Meeting

4.2 Begin review of installation procedures 8 days after Kickoff Meeting

4.2 Complete review of installation procedures 9 days after Kickoff Meeting

4.2 Perform installation 10 days after Kickoff Meeting

4.2 Complete installation 70 days after Kickoff Meeting

4.3 Begin review of testing and validation procedures

71 days after Kickoff Meeting

4.3 Perform testing and validation 73 days after Kickoff Meeting

4.3 Complete testing and validation 77 days after Kickoff Meeting

4.3 Perform pilot of the Interconnect Service 78 days after Kickoff Meeting

4.3 Interconnect Service Production Go Live 81 days after Kickoff Meeting

4.4 Provide Interconnect Services and Support End of Base Year

Option Years 1‐4

Sections Milestones Projected Completion Date

4.4 Provide Interconnect Services and Support End of Each Option Year

Table 1: Project Milestones/Completion Dates

6 Deliverables The ICSP vendor shall provide the deliverables in the format, delivery mechanism, and by the completion date specified in the following table:

Deliverable Task Description Format and Delivery Mechanism

Completion Date

1 4.1 System Design and Architecture

Microsoft Visio (Architecture Diagram) and Microsoft Word (Description), Email to COR

7 days after Kickoff Meeting

2 4.2 Two (2) network circuits from FDA data centers to the ICSP data centers

60 days after Kickoff Meeting

Table 2: Deliverables

7 Inspection and Acceptance The Contracting Officer Representative (COR) shall perform inspection and acceptance of the

Interconnect Services, support, and deliverables specified in Sections 3, 1, and 6. Inspection and

Acceptance will primarily be based on the performance, timely delivery, and meeting the requirements within the POP or established completion dates.

The acceptance criteria for the Interconnect Services and support are the requirements specified in

Section 3 must be fulfilled. The acceptance criteria for the deliverables is they must be reviewed, approved, completed, and delivered to the COR in the format by the completion date specified in Table

2: DeliverablesTable 2: Deliverables in Section 6. The Government will provide written notification of rejection within four (4) hours of receipt. The Government will reject non‐conforming services and deliverables. The Contractor shall correct any deficiencies within three (3) calendar days when the

Government issues the rejection notices. If the Contractor cannot correct the deficiencies within this time frame, the Contractor shall immediately notify the COR of the reason for the delay and provide a proposed corrective action plan within one (1) business days.

8 Government-Furnished Property, Material, Equipment, or Information (GFP, GFM, GFE, or GFI)

This section identifies any Government‐furnished property provided to implement the Interconnect

Service. This includes all Government‐furnished property, such as Government‐furnished material, equipment, or information.

The FDA will acquire outside of this contract any network equipment required to connect from the FDA network to the ICSP. This may include the following equipment:

Routers/switches to be hosted the ICSP data centers

9 Information Security and/or Physical Access Requirement

A. Baseline Security Requirements

1) Applicability. The requirements herein apply whether the entire contract or order (hereafter “contract”), or portion thereof, includes either or both of the following:

2) Access (Physical or Logical) to Government Information: A Contractor (and/or any subcontractor) employee will have or will be given the ability to have, routine physical (entry) or logical (electronic) access to government information.

a. Operate a Federal System Containing Information: A Contractor (and/or any subcontractor) will operate a federal system and information technology containing data that supports the HHS mission. In addition to the Federal Acquisition Regulation (FAR) Subpart 2.1 definition of “information technology” (IT), the term as used in this section includes computers, ancillary equipment (including imaging peripherals, input, output, and storage devices necessary for security and surveillance), peripheral equipment designed to be controlled by the central processing unit of a computer, software, firmware and similar procedures, services (including support services), and related resources.

3) Safeguarding Information and Information Systems. In accordance with the Federal

Information Processing Standards Publication (FIPS)199, Standards for Security Categorization of Federal Information and Information Systems, the Contractor (and/or any subcontractor) shall:

a. Protect government information and information systems in order to ensure:

Confidentiality, which means preserving authorized restrictions on access and disclosure, based on the security terms found in this contract, including means for protecting personal privacy and proprietary information;

Integrity, which means guarding against improper information modification or destruction, and ensuring information non‐repudiation and authenticity; and

Availability, which means ensuring timely and reliable access to and use of information.

b. Provide security for any Contractor systems, and information contained therein, connected to an FDA network or operated by the Contractor on behalf of FDA regardless of location. In addition, if new or unanticipated threats or hazards are discovered by either the agency or contractor, or if existing safeguards have ceased to function, the discoverer shall immediately, within one (1) hour or less, bring the situation to the attention of the other party. This includes notifying the FDA Systems Management Center (SMC) within one (1) hour of discovery/detection in the event of an information security incident.

c. Adopt and implement the policies, procedures, controls, and standards required by the

HHS/FDA Information Security Program to ensure the confidentiality, integrity, and availability of government information and government information systems for which the Contractor is responsible under this contract or to which the Contractor may otherwise have access under this contract. Obtain the FDA Information Security Program security requirements, outlined in the FDA Information Security and Privacy Policy (IS2P), by contacting the CO/COR or emailing your ISSO.

d. Comply with the Privacy Act requirements and tailor FAR clauses as needed.

4) Information Security Categorization. In accordance with FIPS 199 and National Institute of

Standards and Technology (NIST) Special Publication (SP) 800‐60, Volume II: Appendices to Guide for Mapping Types of Information and Information Systems to Security Categories, Appendix C, and based on information provided by the ISSO or other security representative, the risk level for each Security Objective and the Overall Risk Level, which is the highest watermark of the three factors (Confidentiality, Integrity, and Availability) of the information or information system are the following:

Confidentiality: [ ] Low [ X ] Moderate [ ] High Integrity: [ ] Low [ X ] Moderate [ ] High Availability: [ ] Low [ X ] Moderate [ ] High Overall Risk Level: [ ] Low [ X ] Moderate [ ] High

Based on information provided by the Privacy Office, system/data owner, or other privacy representative, it has been determined that this solicitation/contract involves:

[ X ] No PII [ ] Yes PII

5) Controlled Unclassified Information (CUI). CUI is defined as “information that laws, regulations, or Government‐wide policies require to have safeguarding or dissemination controls, excluding classified information.” The Contractor (and/or any subcontractor) must comply with Executive Order 13556, Controlled Unclassified Information, (implemented at 3 CFR, part 2002) when handling CUI. 32 C.F.R. 2002.4(aa). As implemented the term “handling” refers to “…any use of CUI, including but not limited to marking, safeguarding, transporting, disseminating, re‐ using, and disposing of the information.” 81 Fed. Reg. 63323.

All sensitive information that has been identified as CUI by a regulation or statute, handled by this solicitation/contract, shall be:

a. marked appropriately;

b. disclosed to authorized personnel on a Need‐To‐Know basis;

c. protected in accordance with NIST SP 800‐53, Security and Privacy Controls for Federal Information Systems and Organizations applicable baseline if handled by a Contractor system operated on behalf of the agency, or NIST SP 800‐171, Protecting Controlled Unclassified Information in Nonfederal Information Systems and Organizations if handled by internal Contractor system; and

d. returned to FDA control, destroyed when no longer needed, or held until otherwise directed.

Destruction of information and/or data shall be accomplished in accordance with NIST SP 800‐88, Guidelines for Media Sanitization and the FDA IS2P Appendix T: Sanitization of Computer‐Related Storage Media.

6) Protection of Sensitive Information. For security purposes, information is or may be sensitive because it requires security to protect its confidentiality, integrity, and/or availability. The Contractor (and/or any subcontractor) shall protect all government information that is or may be sensitive in accordance with OMB Memorandum M‐06‐16, Protection of Sensitive Agency Information by securing it with a FIPS 140‐2 validated solution.

Confidentiality and Nondisclosure of Information. Any information provided to the contractor (and/or any subcontractor) by FDA or collected by the contractor on behalf of FDA shall be used only for the purpose of carrying out the provisions of this contract and shall not be disclosed or made known in any manner to any persons except as may be necessary in the performance of the contract. The Contractor assumes responsibility for protection of the confidentiality of Government records and shall ensure that all work performed by its employees and subcontractors shall be under the supervision of the Contractor. Each Contractor employee or any of its subcontractors to whom any FDA records may be made available or disclosed shall be notified in writing by the Contractor that information disclosed to such employee or subcontractor can be used only for that purpose and to the extent authorized herein.

The confidentiality, integrity, and availability of such information shall be protected in accordance with HHS and FDA policies. Unauthorized disclosure of information will be subject to the HHS/FDA sanction policies and/or governed by the following laws and regulations:

a. 18 U.S.C. 641 (Criminal Code: Public Money, Property or Records);

b. 18 U.S.C. 1905 (Criminal Code: Disclosure of Confidential Information); and

c. 44 U.S.C. Chapter 35, Subchapter I (Paperwork Reduction Act).

7) Internet Protocol Version 6 (IPv6). All procurements using Internet Protocol shall comply with OMB Memorandum M‐05‐22, Transition Planning for Internet Protocol Version 6 (IPv6).

8) Government Websites. All new and existing public‐facing government websites must be securely configured with Hypertext Transfer Protocol Secure (HTTPS) using the most recent version of Transport Layer Security (TLS). In addition, HTTPS shall enable HTTP Strict Transport Security (HSTS) to instruct compliant browsers to assume HTTPS at all times to reduce the number of insecure redirects and protect against attacks that attempt to downgrade connections to plain HTTP. For internal‐facing websites, the HTTPS is not required, but it is highly recommended.

9) Contract Documentation. The Contractor shall use FDA‐provided templates, policies, forms and other agency documents to comply with contract deliverables as appropriate.

10) Standard for Encryption. The Contractor (and/or any subcontractor) shall:

a. Comply with the HHS Standard for Encryption of Computing Devices and Information to prevent unauthorized access to government information.

b. Encrypt all sensitive federal data and information (i.e., PII, protected health information [PHI], proprietary information, etc.) in transit (i.e., email, network connections, etc.) and at rest (i.e., servers, storage devices, mobile devices, backup media, etc.) with FIPS 140‐2 validated encryption solution.

c. All devices (i.e.: desktops, laptops, mobile devices, etc.) that store, transmit, or process non‐public FDA information should utilize FDA‐provided or FDA information security authorized devices that meet HHS and FDA‐specific encryption standard requirements. Maintain a complete and current inventory of all laptop computers, desktop computers, and other mobile devices and portable media that store or process sensitive government information (including PII).

d. Verify that the encryption solutions in use are compliant with FIPS 140‐2. The Contractor shall provide a written copy of the validation documentation to the COR.

e. Use the Key Management system on the HHS Personal Identification Verification (PIV) card or establish and use a key recovery mechanism to ensure the ability for authorized personnel to encrypt/decrypt information and recover encryption keys. Encryption keys (PIV card) shall be provided to the COR upon request and at the conclusion of the contract. Upon completion of contract, contractor ensures that COR is able to access and read any encrypted data.

11) Contractor Non‐Disclosure Agreement (NDA). Each Contractor (and/or any subcontractor) employee having access to non‐public government information under this contract shall complete the FDA non‐disclosure agreement (3398 Form), as applicable. A copy of each signed and witnessed NDA shall be submitted to the CO and/or COR prior to performing any work under this acquisition.

12) Privacy Threshold Analysis (PTA)/Privacy Impact Assessment (PIA) – The Contractor shall assist the procuring activity representative, program office and the FDA SOP or designee with conducting a PTA for the information system and/or information handled under this contract to determine whether or not a full PIA needs to be completed.

a. If the results of the PTA show that a full PIA is needed, the Contractor shall assist procuring activity representative, program office and the FDA SOP or designee with completing a PIA for the system or information after completion of the PTA and in accordance with HHS and FDA policy and OMB M‐03‐22, Guidance for Implementing the Privacy Provisions of the E‐Government Act of 2002. The PTA/PIA must be completed and approved prior to active use and/or collection or processing of PII and is a prerequisite to agency issuance of an authorization to operate (ATO).

b. The Contractor shall assist the procuring activity representative, program office and the

FDA SOP or designee in reviewing and updating the PIA at least every three years throughout the Enterprise Performance Life Cycle (EPLC) /information lifecycle, or when determined by the agency that a review is required based on a major change to the system, or when new types of PII are collected that introduces new or increased privacy risks, whichever comes first.

B. Training

1) Mandatory Training for All Contractor Staff. All Contractor (and/or any subcontractor) employees assigned to work on this contract shall complete the applicable FDA Contractor Information Security Awareness, Privacy, and Records Management training (provided upon contract award) before performing any work under this contract. Thereafter, the employees shall complete FDA Information Security Awareness, Privacy, and Records Management training at least annually, during the life of this contract. All provided training shall be compliant with HHS and FDA training policies.

2) Role‐based Training. All Contractor (and/or any subcontractor) employees with significant security responsibilities (as determined by the program manager) must complete role‐based training annually commensurate with their role and responsibilities in accordance with HHS and FDA policy and FDA Role‐Based Training (RBT) of Personnel with Significant Security Responsibilities Standard Operating Procedures (SOP).

3) Training Records. The Contractor (and/or any subcontractor) shall maintain training records for all its employees working under this contract in accordance with HHS and FDA policy. A copy of the training records shall be provided to the CO and/or COR within 30 days after contract award and annually thereafter or upon request.

C. Rules of Behavior

1) The Contractor (and/or any subcontractor) shall ensure that all employees performing on the contract comply with the HHS Information Technology General Rules of Behavior.

2) All Contractor employees performing on the contract must read and adhere to the Rules of

Behavior (ROB) before accessing HHS and FDA data or other information, systems, and/or networks that store/process government information, initially at the beginning of the contract and at least annually thereafter, which may be done as part of annual FDA Information Security Awareness Training. If the training is provided by the contractor, the signed ROB must be provided as a separate deliverable to the CO and/or COR per defined timelines.

D. Incident Response

The Contractor (and/or any subcontractor) shall respond to all alerts/Indicators of Compromise (IOCs) provided by HHS Computer Security Incident Response Center (CSIRC)/FDA SMC /Incident Response Team (IRT) teams within 24 hours, whether the response is positive or negative.

FISMA defines an incident as “an occurrence that (1) actually or imminently jeopardizes, without lawful authority, the integrity, confidentiality, or availability of information or an information system; or (2) constitutes a violation or imminent threat of violation of law, security policies, security procedures, or acceptable use policies.” The HHS Policy for IT Security and Privacy Incident Reporting and Response further defines incidents as events involving cybersecurity and privacy threats, such as viruses, malicious user activity, loss of, unauthorized disclosure or destruction of data, and so on.

A privacy breach is a type of incident and is defined by FISMA as the loss of control, compromise, unauthorized disclosure, unauthorized acquisition, or any similar occurrence where (1) a person other than an authorized user accesses or potentially accesses personally identifiable information or (2) an authorized user accesses or potentially accesses personally identifiable information for an other than authorized purpose. The HHS Policy for IT Security and Privacy Incident Reporting and Response further defines a breach as “a suspected or confirmed incident involving PII.”

In the event of a suspected or confirmed incident or breach, the Contractor (and/or any subcontractor) shall:

1) Protect all sensitive information, including any PII created, stored, or transmitted in the performance of this contract to avoid a secondary sensitive information incident with FIPS 140‐2 validated encryption.

2) NOT notify affected individuals unless so instructed by the Contracting Officer or designated representative. If so instructed by the Contracting Officer or representative, the Contractor shall send FDA approved notifications to affected individuals as directed by FDA’s SOP.

3) Report all suspected and confirmed information security and privacy incidents and breaches to the FDA Systems Management Center, COR, CO, and other stakeholders, including incidents involving PII, in any medium or form, including paper, oral, or electronic, as soon as possible and without unreasonable delay, no later than one (1) hour of discovery/detection, and consistent with the applicable FDA and HHS policy and procedures, NIST standards and guidelines, as well as US‐CERT notification guidelines. The types of information required in an incident report must include at a minimum: company and point of contact information, contract information, impact classifications/threat vector, and the type of information compromised. In addition, the Contractor shall:

a. cooperate and exchange any information, as determined by the Agency, necessary to effectively manage or mitigate a suspected or confirmed breach;

b. not include any sensitive information in the subject or body of any reporting e‐mail;

and

c. encrypt sensitive information in attachments to email, media, etc.

4) Comply with OMB M‐17‐12, Preparing for and Responding to a Breach of Personally Identifiable Information and HHS and FDA incident response policies when handling PII breaches.

5) Provide full access and cooperate on all activities as determined by the Government to ensure an effective incident response, including providing all requested images, log files, and event information to facilitate rapid resolution of sensitive information incidents.

This may involve disconnecting the system processing, storing, or transmitting the sensitive information from the Internet or other networks or applying additional security controls. This may also involve physical access to contractor facilities during a breach/incident investigation demand.

E. Position Sensitivity Designations

All Contractor (and/or any subcontractor) employees must obtain a background investigation commensurate with their position sensitivity designation that complies with Parts 1400 and 731 of Title 5, Code of Federal Regulations (CFR). The following position sensitivity designation levels apply to this solicitation/contract:

Tier I and Tier 2

F. Homeland Security Presidential Directive (HSPD)‐12

The Contractor (and/or any subcontractor) and its employees shall comply with Homeland Security Presidential Directive (HSPD)‐12, Policy for a Common Identification Standard for Federal Employees and Contractors; OMB M‐05‐24; FIPS 201, Personal Identity Verification (PIV) of Federal Employees and Contractors; HHS HSPD‐12 policy; and Executive Order 13467, Part 1 §1.2.

Roster. The Contractor (and/or any subcontractor) shall submit a roster by name, position, e‐ mail address, phone number and responsibility, of all staff working under this acquisition where the Contractor will develop, have the ability to access, or host and/or maintain a government information system(s). The roster and any revisions to the roster as a result of staffing changes shall be submitted to the COR and/or CO per the COR or CO’s direction. Any revisions to the roster as a result of staffing changes. The COR will notify the Contractor of the appropriate level of investigation required for each staff member.

If the employee is filling a new position, the Contractor shall provide a position description and the Government will determine the appropriate suitability level.

G. Contract Initiation and Expiration

1) General Security Requirements. The Contractor (and/or any subcontractor) shall comply with information security and privacy requirements, Enterprise Performance Life Cycle (EPLC) processes, HHS Enterprise Architecture requirements to ensure information is appropriately protected from initiation to expiration of the contract. All information systems development or enhancement tasks supported by the contractor shall follow the FDA EPLC framework and methodology in accordance with the HHS Contract Closeout Guide (2012).

HHS EA requirements may be located here:

https://www.hhs.gov/ocio/ea/documents/proplans.html

2) System Documentation. Contractors (and/or any subcontractors) must follow and adhere to NIST SP 800‐64, Security Considerations in the System Development Life Cycle, at a minimum, for system development and provide system documentation at designated intervals (specifically, at the expiration of the contract) within the EPLC that require artifact review and approval.

3) Sanitization of Government Files and Information. As part of contract closeout and at expiration of the contract, the Contractor (and/or any subcontractor) shall provide all required documentation in accordance with FDA OAGS SMGs to the CO and/or COR to certify that, at the government’s direction, all electronic and paper records are appropriately disposed of and all devices and media are sanitized in accordance with NIST SP 800‐88, Guidelines for Media Sanitization and FDA IS2P Appendix T: Sanitization of Computer‐Related Storage Media

4) Notification. The Contractor (and/or any subcontractor) shall notify the CO and/or COR as soon as it is known that an employee will stop working under this contract.

5) Contractor Responsibilities Upon Physical Completion of the Contract. The contractor (and/or any subcontractors) shall return all government information and IT resources (i.e., government information in non‐government‐owned systems, media, and backup systems) acquired during the term of this contract to the CO and/or COR. Additionally, the Contractor shall provide a certification that all government information has been properly sanitized and purged from Contractor‐owned systems, including backup systems and media used during contract performance, in accordance with HHS and/or FDA policies.

6) The Contractor (and/or any subcontractor) shall coordinate with the COR via email, coping the

Contract Specialist, to ensure that the appropriate person performs and documents the actions identified in the FDA eDepart system http://inside.fda.gov:9003/EmployeeResources/NewEmployee/eDepartDepartureSystem/de fault.htm as soon as it is known that an employee will terminate work under this contract within days of the employee’s exit from the contract. All documentation shall be made available to the CO and/or COR upon request.

H. Records Management and Retention The Contractor (and/or any subcontractor) shall maintain all information in accordance with Executive Order 13556 ‐‐ Controlled Unclassified Information, National Archives and Records Administration (NARA) records retention policies and schedules and HHS/FDA policies and shall not dispose of any records unless authorized by HHS/FDA.

In the event that a contractor (and/or any subcontractor) accidentally disposes of or destroys a record without proper authorization, it shall be documented and reported as an incident in accordance with HHS/FDA policies.

10 Contractor-Owned/Contractor-Operated Security Requirements A. Security Requirements for GOCO and COCO Resources

1) Federal Policies. The Contractor (and/or any subcontractor) shall comply with applicable federal laws that include, but are not limited to, the FDA Information Security and Privacy Policy (IS2P), Federal Information Security Modernization Act (FISMA) of 2014, (44 U.S.C.

101); National Institute of Standards and Technology (NIST) Special Publication (SP) 800‐53, Security and Privacy Controls for Federal Information Systems and Organizations; Office of Management and Budget (OMB) Circular A‐130, Managing Information as a Strategic Resource; and other applicable federal laws, regulations, NIST guidance, and Departmental policies.

2) Security Assessment and Authorization (SA&A). A valid authorization to operate (ATO) certifies that the Contractor’s information system meets the contract’s requirements to protect the agency data. If the system under this contract does not have a valid ATO, the Contractor (and/or any subcontractor) shall work with the agency and supply the deliverables required to complete the ATO within the specified timeline(s). The Contractor shall conduct the SA&A requirements in accordance with FDA IS2P, NIST SP 800‐ 37, Guide for Applying the Risk Management Framework to Federal Information Systems: A Security Life Cycle Approach (latest revision).

For an existing ATO, FDA must make a determination if the existing ATO provides appropriate safeguards or if an additional ATO is required for the performance of the contract and state as such.

FDA acceptance of the ATO does not alleviate the Contractor’s responsibility to ensure the system security and privacy controls are implemented and operating effectively.

a. SA&A Package Deliverables ‐ The Contractor (and/or any subcontractor) shall provide an SA&A package within a timeline directed by the COR, per to FDA EPLC process, to the CO and/or COR. The following SA&A deliverables are required to complete the SA&A package:

System Security Plan (SSP) – due a week prior to the start of the annual security assessment. The SSP shall comply with the NIST SP 800‐18, Guide for Developing Security Plans for Federal Information Systems, the Federal Information Processing Standard (FIPS) 200, Recommended Security Controls for Federal Information Systems, and NIST SP 800‐53, Security and Privacy Controls for Federal Information Systems and Organizations applicable baseline requirements, and other applicable NIST guidance as well as HHS and FDA policies and other guidance. The SSP shall be consistent with and detail the approach to IT security contained in the Contractor’s bid or quotation that resulted in the award of this contract. The SSP shall provide an overview of the system environment and security requirements to protect the information system, as well as describe all applicable security controls in place or planned for meeting those requirements. It should provide a structured process for planning adequate, cost‐effective security protection for a system. The Contractor shall update the SSP at least annually thereafter. Security Assessment Plan/Report (SAP/SAR) – due before the system is made available to standard users. The security assessment shall be conducted by FDA’s team of security assessors, unless otherwise noted and be consistent with NIST SP 800‐53A, NIST SP 800‐30, and HHS and FDA policies. The assessor will document the assessment results in the SAR.

Independent Assessment – This shall be coordinated through the FDA Information Security program.

POA&M – due as part of the SAR. The POA&Ms shall be documented consistent with the HHS and FDA Standard for Plan of Action and Milestones and FDA policies.

All high‐risk weaknesses must be mitigated within 30 and all medium weaknesses must be mitigated within [60 from the date the weaknesses are formally identified and documented. FDA’s assessors will determine the risk rating of vulnerabilities.

Identified risks stemming from deficiencies related to the security control baseline implementation, assessment, continuous monitoring, vulnerability scanning, and other security reviews and sources, as noted in the SAR, shall be documented and tracked by the Contractor for mitigation in the POA&M document. Depending on the severity of the risks, FDA may require designated POA&M weaknesses to be remediated before an ATO is issued. Thereafter, the POA&M shall be updated at least quarterly.

Contingency Plan and Contingency Plan Test – due before the start of the annual security assessment. The Contingency Plan must be developed in accordance with NIST SP 800‐34, Contingency Planning Guide for Federal Information Systems, and be consistent with HHS and FDA policies. Upon acceptance by the System Owner, the Contractor, in coordination with the System Owner, shall test the Contingency Plan and prepare a Contingency Plan Test Report that includes the test results, lessons learned and any action items that need to be addressed. Thereafter, the Contractor shall update and test the Contingency Plan at least annually.

E‐Authentication Questionnaire – The contractor (and/or any subcontractor) shall collaborate with government personnel to ensure that an E‐Authentication Threshold Analysis (E‐Auth TA) is completed to determine if a full E‐Authentication Risk Assessment (E‐Auth RA) is necessary.