POTS 20-002611 DRD Blackford Platform License Support Security Clauses.docx

Security and Privacy Guide for Information Technology Acquisition v2 Page 1

Security and Privacy Language for Information and Information Technology Procurements Version 2.2 September 7, 2017

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:

a. 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. Contractor personnel who need to be on-site to perform service and maintenance must be escorted and monitored at all times. A NDA must be signed if services and maintenance requires access PII/PHI or sensitive government information.

2) 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 HHS network or operated by the Contractor on behalf of HHS 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.

c. Adopt and implement the policies, procedures, controls, and standards required by the HHS 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 HHS Information Security Program security requirements, outlined in the HHS Information Security and Privacy Policy (IS2P), by contacting the CO/COR or emailing fisma@hhs.gov.

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

3) 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, CISO, 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:

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

[ ] No PII [x] Yes PII

Personally Identifiable Information (PII). Per the Office of Management and Budget (OMB) Circular A-130, “PII is information that can be used to distinguish or trace an individual's identity, either alone or when combined with other information that is linked or linkable to a specific individual.” Examples of PII include, but are not limited to the following: social security number, date and place of birth, mother‘s maiden name, biometric records, etc.

PII Confidentiality Impact Level has been determined to be: [x] Low [ ] Moderate [ ] High

4) 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.

5) Confidentiality and Nondisclosure of Information. Any information provided to the contractor (and/or any subcontractor) by HHS or collected by the contractor on behalf of

HHS Security and Privacy Language for Information and Information Technology Procurements v2

HHS 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 HHS 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 NIH policies. Unauthorized disclosure of information will be subject to the HHS/NIH 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 (Crimi1nal Code: Disclosure of Confidential Information); and

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

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

7) 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 NIH non-disclosure agreement. A copy of each signed and witnessed NDA shall be submitted to the Contracting Officer (CO) and/or CO Representative (COR) prior to performing any work under this acquisition.

8) System Interconnection Security Agreement (ISA) and Memorandum of Understanding (MOU). Systems that interconnect exchange or share sensitive information need to meet the OMB A-130 requirement that "written management authorization (often in the form of a Memorandum of Understanding or Agreement,) be obtained prior to connecting with other systems and/or sharing sensitive data/information. The written authorization shall detail the rules of behavior and controls that must be maintained by the interconnecting systems." To meet this requirement it is required a System Interconnection Security Agreement (ISA) and Memorandum of Understanding (MOU) focused on protecting the data exchanged.

An MOU and/or ISA will be required for any remote vendor access the NIHnet in order to ensure adequate security and the protection of the NIHnet.

NIH ISA Template and NIH MOU Template are available at https://ocio.nih.gov/InfoSecurity/Policy/Pages/NIH_ISA_Templates.aspx

B. 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)/ NIH 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 Federal Information Security Modernization Act (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 so as 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 NIH approved notifications to affected individuals.

3) Report all suspected and confirmed information security and privacy incidents and breaches to the NIH Incident Response Team (IRT), COR, CO, NIH SOP (or his or her designee), 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, and consistent with the applicable NIH 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 HHS/NIH 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.

1 CC Remote Access Options The following options and associated processes described below are acceptable and approved methods of remote access into Clinical Center IT and medical systems. Responsible parties requesting remote access must meet all required security requirements as listed per the selected option.

Option 1: Non-Persistent Remote Access (e.g. GoToMeeting, WebEx) This option is for ad-hoc or as needed communications that may be needed within NIH or between NIH and external parties where a persistent/continuous connection is not required.

Requirements:

· CC staff must initiate the connection with the external party, monitor activities, retain a log of the external party’s name, date/time and purpose of the connection, and terminate the connection when activities are completed

· NIH technical representative will need to be available for initiating and terminating the connection.

· No ISA/MOU is needed

· PIV or NIH Active Directory (AD) account is NOT required

Option 2: CC CITRIX (Casper) The CC Casper/Citrix option meets NIH Remote Access Standards and can be used for remote access to CC systems. CC Citrix can be accessed via: https://cccasper.cc.nih.gov. No local desktop storage or local printing options are allowed using Citrix remotely. Data can be stored/saved on assigned shared drives if needed.

Requirements:

· Must be sponsored for PIV card, obtain NIH AD Account, and have background investigation completed (see Option 3 for details). In addition, NIH Clinical Center Administrative Account (AA) request must be obtained for remote administration of CC servers (follow CC AA Process).

· If using government furnished equipment (GFE), contact the User Support Team (UST) to obtain PIV card reader for user’s workstation/laptop, and configure workstation

· For Non-GFE personal computers, guidance for configuration of PIV readers and installation of Active Identity is available at https://ocio.nih.gov/Smartcard/Pages/default.aspx

· Must install Citrix Client Software (Citrix Receiver)

· Must contact CC Citrix Team to put user in appropriate group to allow for Citrix use for non-CC users

· May use Citrix to Remote Desktop Protocol (RDP) to access local workstation/server

· ISA/MOU required for vendor remote access to CC systems

Option 3: NIH Virtual Private Network (VPN) The NIH VPN can be used to provide a secure, encrypted connection to the NIH network and resources.

Requirements:

· Must be sponsored by Administrative Officer (AO) to utilize the NIH VPN Identity Services Engine (ISE)

· Must be sponsored for PIV card (through the AO) and obtain NIH AD Account. In addition, NIH Clinical Center Administrative Account (AA) request must be obtained for remote administration of CC servers (follow CC AA Process).

· Must have background investigation completed.

· For general access to the NIH network, users will need Level 1 Non-Sensitive (OPM National Agency Check with Inquiries (NACI) Background Check). Cost is approximately $103 for contract staff. Department sponsoring the contractor is responsible for funding.

· For remote system maintenance and administration, a Level 5 Moderate Risk Public Trust will be necessary. Cost is approximately $2,500 for contract staff.

· Department sponsoring the contractor is responsible for funding.

Note: Background Investigation costs may vary and/or change. Please check with your AO on exact costs.

· Must complete security training: Secure Your Remote Computers training, Annual Security & Privacy refresher training

· GFE (e.g. Laptop) must be issued to the contractor.

· May use NIH VPN to RDP to access local workstation/server

· ISA/MOU is required for vendor remote access to CC systems

Option 4: CC VPN The CC VPN, managed by the CC DCRI Network Administrator team, is used to allow remote administration of CC servers that are behind the Clinical Center firewall(s)\.

Requirements:

· Must be sponsored for PIV card, obtain NIH AD Account, and have background investigation completed (see Option 3 for details)

· GFE (e.g. laptop) must be issued to contractor

· PMO office and/or senior management will validate or sponsor any vendor request and will send the request to the DCRI Network Admin team to provide remote CC VPN access.

· Specific background configuration of the CC managed firewall(s) by the DCRI Network Admin team is needed to allow access to resources. All devices are not given access to CC VPN by default.

· ISA/MOU is required for vendor remote access to CC systems

Option 5: Vendors with larger maintenance support staff (over 10 or more) for use of NIH VPN (Option 3) or CC VPN (Option 4) This option is for vendors who have a large rolling staff that would like to use NIH VPN (Option

3) or CC VPN (Option 4).

· Vendor selects limited staff members (2 to 5 contractors) to support Clinical Center systems

· Vendor limited staff members must be sponsored by Administrative Officer (AO) as stated in Option 3 or 4.

· Vendor limited staff members must access NIH system via option 2, 3 or 4 (as defined above)

· Vendor limited staff members must initiate the connection

· Vendor limited staff members must monitor all actions

· Vendor limited staff members must terminate the connection

· Vendor limited staff members will be held responsible for any actions taken by other vendor staff during that session

· Vendor limited staff members must keep a log of the name, role, and actions taken by the other vendor staff; this log may be requested at any time by the NIH

Option 6: Waiver Process Deviations to this policy and the NIH Remote Access Standard shall be addressed through the CC Waiver process.

1. System owner shall email the CC Information Security Office (ccsecurity@mail.nih.gov) for a review of the CC Waiver Process.

2. System owner shall write a summary that includes a review of each of the options and a justification of why Options 1-5 are not possible for the respective system. The summary shall include alternate proposed remote access solution(s).

3. System owner shall schedule a meeting with the CC CISO and the C CIO to review the written summary.

4. If a temporary waiver is approved, the system owner shall follow the CC Waiver Process to create and complete the waiver.

5.

APPENDIX A: NIH Remote Access Standard

NIH Remote Access Standard

Purpose: This standard establishes requirements to ensure that NIH information technology (IT) resources are appropriately protected when authorized staff remotely access the NIH network.

Scope: All NIH IT resources, whether maintained by the NIH or by a contractor on behalf of the NIH; the NIH enterprise remote access service; IC-managed remote access solutions that have been approved (as exceptions) by the NIH Chief Information Security Officer (CISO); and wireless remote access to the NIH network via laptops (which must also meet the requirements in the NIH Wireless Network Security Standard). Mobile devices such as smart phones and tablets are addressed under the NIH Mobile Device Security Standard.

Standard:

1. The NIH enterprise remote access service is preferred, and is available for all Institutes and Centers (IC).

2. If the IC has a business need that cannot be satisfied by the NIH enterprise method, the IC may establish a remote access method (with approval by the CISO) that meets the following requirements: a. The remote access service must require Personal Identity Verification (PIV) authentication for connection.

b. The remote access service must reside in a public-facing network segment or DMZ.

c. All remote access logs must be forwarded to the NIH enterprise logging solution.

Compliance: Where deviations from this standard are necessary, requests for exceptions should be submitted through the IRT Portal at https://irtportal.ocio.nih.gov/, and will be evaluated by the NIH CISO.

APPENDIX B: System Monitoring by External Vendors The NIH Clinical Center recognizes the need to enable system monitoring by external vendors to support and maintain medical devices and/or other systems for performance, health checks, or other reasons to ensure the availability of critical equipment for patient care.

The purpose of the document above, NIH Clinical Center Policy for Remote Access to IT & Medical Systems Policy, is to establish streamlined and acceptable methods of remote access by vendors into internal NIH resources for maintenance and troubleshooting purposes when human intervention is required.

This document was developed to establish acceptable methods of monitoring system health and status on NIH CC systems via vendor systems where the connection is purely from CC systems to vendor systems and no human intervention is required. The options listed below ensure the security posture of the NIH network, while enabling system monitoring from an external site to CC systems.

Figure 1 Site to Site VPN

Option 1: Site-to-Site VPN for Bi-directional Communication This option is for a business need to have persistent bi-lateral communication between Clinical Center systems and external vendor systems

Requirements:

· Must have Interconnection Security Agreements (ISAs) and Memorandum of Understanding (MOUs) prior to VPN activation

· The agreement with the vendor must specify any reporting caveats and explicitly state that the connection is strictly System-to-System for monitoring device health and status

· Must have an approved firewall waiver on file to open ports to the external vendor

· Source and destination of the traffic must be limited to a specific IP address, IP range, ports, and/or VLAN

· The connections must utilize FIPS 140-2 validated encryption and restricted to specific ports, as well as direction

· Remote access logs must be forwarded to the NIH enterprise Security Information and Event Management (SIEM) solution

· The vendor must limit access to NIH data stored on vendor systems to authorized personnel with a valid need to view/access the data

· The vendor must ensure all NIH data stored on vendor systems are protected and secured adequately based on the classification of the data

· Information transmitted outside the NIH network must be minimized to include only the necessary data required for monitoring

· System Owner shall consult with the CC Information Security Office if transmitting sensitive, PHI, or PII data outside the NIH network

Figure 2 One-directional Connection

Option 2: One-directional Remote Monitoring and/or Alerting Remote system monitoring using agents or third party software to transmit health, status and/or alert information.

Requirements:

· Internal component (agent or third party utility) sends status/health check type of information to a specific vendor destination/system

· Must have an approved firewall waiver on file to open specific ports to the external vendor

· Source and destination of the traffic must be limited to a specific IP address, IP range, port, and/or VLAN

· Traffic must be one way (from internal NIH to the vendor), utilize Federal Information Processing Standards (FIPS) 140-2 validated encryption and restricted to specific ports

· Remote access logs must be forwarded to the NIH enterprise Security Information and Event Management (SIEM) solution

· The vendor must limit access to NIH data stored on vendor systems to authorized personnel with a valid need to view/access the data

· The vendor must ensure all NIH data stored on vendor systems are protected and secured adequately based on the classification of the data

· Information transmitted outside the NIH network must be minimized to include only the necessary data required for monitoring

· System Owner shall consult with the CC Information Security Office if transmitting sensitive, PHI, or PII data outside the NIH network

Figure 3 Intermediary Repository Connection

Option 3: Intermediary Repository for Hosting System Monitoring Data Use of an intermediate repository, located behind the NIH perimeter firewall, to receive and store the system monitoring data from the NIH CC medical device. The vendor system is responsible for initiating the connection to view the information from the NIH CC repository system.

Requirements:

· Internal component (agent or third party utility) must be able to write system health and monitoring data to a repository

· Vendor must be able to use secure authentication to view data from CC repository system located behind the NIH perimeter firewall (preferably in the CC DMZ)

· Must have an approved firewall waiver on file to open ports to the external vendor

· Source and destination of the traffic must be limited to a specific IP address, IP range, ports, and/or VLAN

· The connections must utilize FIPS 140-2 validated encryption and restricted to specific ports, as well as direction

· Remote access logs must be forwarded to the NIH enterprise Security Information and Event Management (SIEM) solution

· The vendor must limit access to NIH data stored on vendor systems to authorized personnel with a valid need to view/access the data

· The vendor must ensure all NIH data stored on vendor systems are protected and secured adequately based on the classification of the data

· Information transmitted outside the NIH network must be minimized to include only the necessary data required for monitoring

· System Owner shall consult with the CC Information Security Office if transmitting sensitive, PHI, or PII data outside the NIH network image230.jpeg image3.jpeg image240.jpeg image4.jpeg image250.jpeg image2.jpeg image1.jpeg