POTS_19-007408_DRD_Biopsy_Software_Renewal_Security_Clause.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.

b. 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.

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 [ ] Yes PII Complete this section using the information obtained from the Security and Privacy Checklist in Appendix A, parts A and B.

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: [ ] Low [ ] Moderate [ ] High

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

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

See the HHS Standard for the Definition of Sensitive Information, for additional information in defining and protecting sensitive information.

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

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 provided templates, policies, forms and other agency documents to comply with contract deliverables as appropriate.

See Appendix D for baseline deliverables.

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. Secure all devices (i.e.: desktops, laptops, mobile devices, etc.) that store and process government information and ensure devices meet HHS and NIH-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 have been validated under the Cryptographic Module Validation Program to confirm compliance 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 shall be provided to the COR upon request and at the conclusion of the contract.

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

12) 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

13) Privacy Threshold Analysis (PTA)/Privacy Impact Assessment (PIA) – The Contractor shall assist the NIH Senior Official for Privacy (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 the NIH SOP or designee with completing a PIA for the system or information after completion of the PTA and in accordance with HHS policy and OMB M-03-22, Guidance for Implementing the Privacy Provisions of the E-Government Act of 2002.

b. The Contractor shall assist the NIH SOP or designee in reviewing the PIA at least every three years throughout the system development lifecycle (SDLC)/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 HHS/NIH 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 NIH 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 training policies.

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 policy and the HHS Role-Based Training (RBT) of Personnel with Significant Security Responsibilities Memorandum.

2) Training Records. The Contractor (and/or any subcontractor) shall maintain training records for all its employees working under this contract in accordance with HHS 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 before accessing Department 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 NIH 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 above.

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

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:

The requiring activity representative, in conjunction with Personnel Security, shall use the OPM Position Sensitivity Designation automated tool (https://www.opm.gov/investigations/) to determine the sensitivity designation for background investigations. After making those determinations, include all applicable position sensitivity designations.

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.

For additional information, see HSPD-12 policy at: https://www.dhs.gov/homeland-security-presidential- directive-12)

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 shall be submitted to the COR and/or CO. 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 HHS EPLC framework and methodology and 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 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.

4) Notification. The Contractor (and/or any subcontractor) shall notify the CO and/or COR and system ISSO before an employee stops 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 NIH policies.

6) The Contractor (and/or any subcontractor) shall perform and document the actions identified in the NIH Contractor Employee Separation Checklist when an employee terminates work under this 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/NIH policies and shall not dispose of any records unless authorized by HHS/NIH

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/NIH policies.

1. Requirements for Procurements Involving Privacy Act Records

3.A. Privacy Act

It has been determined that this contract is subject to the Privacy Act of 1974, because this contract provides for the design, development, or operation of a system of records on individuals.

The System of Records Notice (SORN) that is applicable to this contract is: [OpDiv insert SORN number if one exists. If there is no SORN, indicate that a SORN will be developed. CC Privacy Office will supply when reviewing procurement request.].

The design, development, or operation work the Contractor is to perform is: [OpDiv insert description of design, development, and/or operation work; see definitions in the FAR at 24.101 - Definitions].

The disposition to be made of the Privacy Act records upon completion of contract performance is: [OpDiv insert records disposition instructions the contractor and any subcontractor must follow upon completion of contract performance. Needs input from Tricia Coffey who is CC Records Management Liaison for CC.].

3.B. Privacy Incident Handling and Notification

The Contractor (and/or any subcontractor) shall obtain notification instructions and approval from the Contracting Officer prior to notifying individuals whose PII resided in the Contractor (and/or any subcontractor) IT system at the time of the incident. The method and content of any notification by the Contractor shall be compliant with HHS Privacy Incident Response Team (PIRT) Standard Operating Procedures (SOP) (http://intranet.hhs.gov/it/cybersecurity/docs/incident_mgmt/PIRTSOP/pirt_sop.pdf ) and NIH Guidance as well as coordinated and approved by the HHS PIRT in consultation with the Contracting Officer, the NIH SAOP (or his or her designee), and/or Computer Security Incident Response Team (CSIRT). Upon receiving notification and approval from the agency Contracting Officer, the Contractor shall send notifications to affected individuals within [NIH Specific timeline].

(Note: The Contractor (and/or any subcontractor) shall not proceed with any notification to individuals unless the Contracting Officer, in consultation with the HHS PIRT and NIH SAOP, has determined in writing that the Contractor notification is appropriate.)

3.B.1. All determinations related to privacy incidents, including response activities, notifications to affected individuals and/or federal agencies, and related services (e.g., credit monitoring and identity protection) will be made in writing by the Contracting Officer in consultation with the HHS PIRT, NIH CIO, and SAOP (or his or her designee) and in compliance with HHS and/or NIH Guidance.

3.B.2. The Contractor (and/or any subcontractor) shall provide full access and cooperation for all activities determined by the Government to be required to ensure an effective incident response, including providing all requested images, log files, and event information to facilitate rapid resolution of sensitive information incidents. Incident response activities determined to be required by the Government may include, but are not limited to, the following:

1. Inspections,

2. Investigations,

3. Forensic reviews, and

4. Data analysis and processing.

3.C. Privacy Act

3.C.1. Privacy Act Notification (FAR Clause 48 CFR § 52.224-1). The Contractor (and/or any subcontractor) shall comply with FAR Clause 48 CFR § 52.224-1 requirements, which can be located at: https://www.acquisition.gov/sites/default/files/current/far/html/52_223_226.html

3.C.2. Privacy Act (FAR Clause 48 CFR § 52.224-2). The Contractor (and/or any subcontractor) shall comply with FAR Clause 48 CFR § 52.224-2 requirements, which can be located at: https://www.acquisition.gov/sites/default/files/current/far/html/52_223_226.html

3.C.3. Privacy Act (HHSAR Clause 48 CFR §352.224-70). The Contractor (and/or any subcontractor) shall comply with HHSAR Clause 48 CFR §352.224-70 requirements, which can be located at: https://www.hhs.gov/grants/contracts/contract-policies-regulations/hhsar/part-352-solicitation-provisions-contract-clauses/index.html#352.224-70

A. Information Technology Application Design, Development, or Support

1) The Contractor (and/or any subcontractor) shall ensure IT applications designed and developed for end users (including mobile applications and software licenses) run in the standard user

25 Purchasing of Noncommercial Computer Software and Open Source Licenses (2012) information may be found at http://www.hhs.gov/ocio/policy/purchasing_noncommercial_computer_software.html 26 OMB M-04-16, Software Acquisition, July 1, 2004, may be found at https://obamawhitehouse.archives.gov/omb// context without requiring elevated administrative privileges.

2) The Contractor (and/or any subcontractor) shall follow secure coding best practice requirements, as directed by United States Computer Emergency Readiness Team (US-CERT) specified standards and the Open Web Application Security Project (OWASP), that will limit system software vulnerability exploits.

3) The Contractor (and/or any subcontractor) shall ensure that computer software developed on behalf of HHS or tailored from an open-source product, is fully functional and operates correctly on systems configured in accordance with government policy and federal configuration standards. The contractor shall test applicable products and versions with all relevant and current updates and patches updated prior to installing in the HHS environment. No sensitive data shall be used during software testing.

4) The Contractor (and/or any subcontractor) shall protect information that is deemed sensitive from unauthorized disclosure to persons, organizations or subcontractors who do not have a need to know the information. Information which, either alone or when compared with other reasonably-available information, is deemed sensitive or proprietary by HHS shall be protected as instructed in accordance with the magnitude of the loss or harm that could result from inadvertent or deliberate disclosure, alteration, or destruction of the data. This language also applies to all subcontractors that are performing under this contract.

HHS Standard for Encryption of Computing Devices and Information

1. Standards

1.1 HHS Encryption Standard

All encryption solutions used throughout the Department and referenced throughout this document must be Federal Information Processing Standard (FIPS) 140-2 validated.6 OpDivs and StaffDivs shall ensure FIPS 140-2 validated encryption solutions are available to all users to ensure sensitive data are appropriately secure while at rest and in transit.

2.1.1 Device Encryption

1) Servers that authenticate, store, process, and/or transmit sensitive information shall be encrypted. If server encryption is not technically feasible, all folders and/or files containing sensitive information must be encrypted. The implemented level of encryption must be sufficient to mitigate the risk severity.7

2) Whole disk encryption or container encryption shall be employed on all desktops, laptops and mobile/portable devices. 8

3) Loaner laptops and other GFE used for foreign travel9 shall be encrypted.10 No sensitive data shall be stored at any time on any unencrypted GFE or non-GFE.

(Note: Some foreign countries may have different encryption standards or not allow encryption altogether. Consult with HHS Office of Security and Strategic Information (OSSI) and the OpDiv IT Department for additional information prior to requesting equipment for foreign travel).11

4) All storage media [e.g. Universal Serial Bus (USB) drives, Compact Disc Read-Only Optical Memory (CD-ROM), Digital Versatile Disc (DVD), etc.] shall be encrypted to protect the confidentiality and integrity of sensitive information. Legacy devices that do not employ encryption capabilities [e.g. magnetic media, backup tapes, Advanced Technology Attachment (ATA) and Small Computer System Interface (SCSI) hard drives, floppy disks, and zip drives] shall not be allowed to store sensitive information unless they are secured in OpDiv-defined controlled environments or other compensating controls are implemented.

1 All cryptographic products must be tested and validated under the Cryptographic Module Validation Program to confirm compliance with the requirements of FIPS Publication 140-2 (as amended), http://csrc.nist.gov/cryptval; NIST SP 800-175B Guideline for Using Cryptographic Standards in the Federal Government: Cryptographic Mechanisms, http://csrc.nist.gov/publications/PubsSPs.html.

2 For example, a server storing highly sensitive information, such as payroll data, whole disk encryption would not be sufficient to protect information at rest. Files and folders should also be encrypted.

3 HHS Memo Encryption Plan Format for Protection of Sensitive Information 2008-06-16, http://intranet.hhs.gov/it/cybersecurity/policies/index.html.

4 More information may be found in the HHS Memorandum on the Use of Government Furnished Equipment (GFE) During Official Foreign Travel, http://intranet.hhs.gov/it/cybersecurity/policies/.

5 If the country you’re traveling to doesn’t allow encryption or has different encryption requirements, an approved waiver must be obtained prior to taking GFE to foreign country.

6 OSSI Intranet Site: http://intranet.hhs.gov/security/ossi-general/index.html.

5) All photocopiers, printers, fax machines, and multifunctional machines that have storage data transmission capability, shall be encrypted.12

6) Personally-owned mobile telephones, tablets, and other smart and storage devices shall not be used to store and access government sensitive information, unless granted exception and managed by an approved enterprise mobile device management (MDM) solution and encryption mechanism.13 The MDM solution must be configured to the most restrictive settings practicable (in accordance with OpDiv policies) and include separate data containers to segregate HHS information from personal information and allow for remote wipe in the event of an incident involving HHS information.

2.1.2 Information Encryption

All sensitive information at rest and in transit shall be encrypted to safeguard the confidentiality and integrity of information. If encrypting such information is not technically feasible or demonstrably affects the ability of OpDivs/StaffDivs to carry out their respective missions, functions, or operations, the OpDiv Authorizing Official, in consultation with the Senior Agency Official for Privacy (SAOP) (as applicable)14 must accept the risk and demonstrate that compensatory controls have been implemented to protect sensitive information.

Data at Rest

Sensitive data stored either on GFE or non-GFE (contractor owned) shall be safeguarded in accordance with NIST guidance15 and the HHS Information Security and Privacy Policy (IS2P), as amended, including but not limited to:

· Folders/files containing sensitive PII or other sensitive data stored in shared drive shall be encrypted and the folders configured to restrict access on a need-to-know basis;

· Data backups shall be encrypted and securely transported/filed/archived.

· For high-impact systems, cryptographic mechanisms shall be employed to protect the integrity of audit information (e.g. log, and audit tools).16

Data in Transit

1) Confidentiality and integrity of remote access sessions and sensitive information shall be protected with end-to-end encryption commensurate with the sensitivity level of the data.

2) Email and any attachment that contains sensitive information when transmitted inside and outside of HHS premises shall be encrypted using the user’s Personal Identity

7 Data such as device passwords, configuration settings, or processed jobs may appear to be unreadable but are exploitable if it is not encrypted. See NISTIR 8023 Risk Management for Replication Devices, page 8 for additional information.

8 MDM capabilities include, but are not limited to user administration, geo-location services, remote lock services, remote wipe services, application installation, records retention, eDiscovery, legal hold, and FOIA search and preserve capability.

9 The OMB Circular A-130 Managing Federal Information as a Strategic Resource, https://www.whitehouse.gov/sites/default/files/omb/assets/OMB/circulars/a130/a130revised.pdf.

10 NIST SP 800-111 Guide to Storage Encryption Technologies for End User Devices, November 2007, http://csrc.nist.gov/publications/PubsSPs.html.

11 See HHS IS2P, AU-9(3).

Verification (PIV) card when possible.17 If PIV encryption is not feasible, a FIPS 140-2 validated solution must be employed:

· Password protection of files are recommended to add an additional layer of data protection but shall not be used in lieu of encryption solutions.

· Password and/or encryption key shall not be included in the same email that contains sensitive information or in separate email. Password/encryption key shall be provided to the recipient separately via text message or verbally.

1.2 Public Key Infrastructure (PKI)

1) For all devices containing HHS sensitive information, the following shall be in place:

· Encryption keys compliant with HHS and OpDivs policies with the necessary controls to prevent unauthorized decryption of the information.18

· A key recovery mechanism to decrypt and access the encrypted information by authorized personnel with legitimate need-for-access. Use of encryption keys which are not recoverable by authorized personnel shall be prohibited. OpDivs shall implement a process that requires approval by authorized senior management or the OpDiv Chief Information Security Officer (CISO) to authorize recovery of keys by someone other than the key owner.19

2) All public key certificates used by the OpDiv/StaffDiv shall be issued in accordance with Federal PKI policy and validated to the Federal PKI trust anchor when being used for user signing, encrypting purposes, authentication, and authorization20

3) Digital signature capabilities shall be implemented in accordance with Federal PKI policy, and NIST standards and guidelines. For employees and contractors, OpDiv/StaffDiv shall use the digital signature capability of PIV credentials. For individuals that fall outside the scope of PIV applicability, agencies shall leverage approved Federal PKI credentials when using digital signatures.

1.3 Websites and Web Services

1) All publicly accessible federal websites and web services shall employ secure connections, such as Hypertext Transfer Protocol Secure (HTTPS). HTTPS may be employed on Intranets but is not explicitly required.21

12 HHS Cybersecurity Program - Encryption, Guide to Outlook Email Encryption Using an HHS PIV card, http://intranet.hhs.gov/it/cybersecurity/enterprise_security/Encryption/index.html.

13 NIST SP 800-56A Recommendation for Pair-Wise Key Establishment Schemes Using Discrete Logarithm Cryptography; SP 800-57 Recommendation for Key Management, NIST SP 800-131A Transitions: Recommendations for Transitioning the Use of Cryptographic Algorithms and Key Lengths; and NIST SP 800-175B Guideline for Using Cryptographic Standards in the Federal Government: Cryptographic Mechanisms; and HHS policy Public Key Infrastructure, http://www.hhs.gov/ocio/securityprivacy/publickey/pki.html.

14 HHS Enterprise Public Key Infrastructure (PKI), http://intranet.hhs.gov/security-pki/index.html#_Enterprise_PKI_Services. 20 OMB Circular A-130, https://www.whitehouse.gov/sites/default/files/omb/assets/OMB/circulars/a130/a130revised.pdf.

21 OMB Memorandum M-15-13 Policy to Require Secure Connections across Federal Websites and Web Services, https://www.whitehouse.gov/sites/default/files/omb/memoranda/2015/m-15-13.pdf.

2) HTTPS is a combination of HTTP and the network protocol Transport Layer Security (TLS), which establishes an encrypted connection to an authenticated peer over an untrusted network. OpDivs/StaffDivs shall use the most current TLS version. TLS shall be implemented and configured in accordance with the recommendation of NIST SP 800-5222 as amended. OpDivs shall monitor the HHS OCIO website, intranet and other public resources to keep apprised of current best practices.

3) OpDiv websites and services shall deploy HTTPS in a manner that allows for rapid updates to certificates, cipher choices protocol versions, and other configuration elements.

4) Websites and services available over HTTPS shall enable HTTP Strict Transport Security (HSTS) to instruct compliant browsers to assume HTTPS going forward. This reduces the number of unsecure redirects and protects users against attacks that attempt to downgrade connections to plain HTTP. Once HSTS is in place, domains can be submitted to a “preload list” used by all major browsers to ensure the HSTS policy is in effect at all times.

5) Allowing HTTP connections for the sole purpose of redirecting clients to HTTPS connections shall be acceptable and encouraged. HSTS headers must specify a max- age of at least 1 year.23

1.4 HHS Contracts

All HHS contracts shall include encryption language to ensure contractors and third-party service providers, handling, storing and/or processing government sensitive information, protect such information in accordance with the Federal Acquisition Regulation (FAR), the HHS Acquisition Regulation,24 this Standard, and other HHS policies

1.5 Incident Handling

1) All security and privacy incidents shall be immediately reported to the OpDiv Security Incident Response Team (CSIRT) and/or OpDiv Helpdesk. The OpDiv CSIRT or Help Desk will notify the HHS Computer Security Incident Response Center (CSIRC) after assessing the situation, responding to any immediate requirements, and collecting essential information about the incident.25 These include, but are not limited to:

· Loss or theft of any equipment that contains sensitive information, even if the information and device are encrypted;

· Loss of PIV card or compromised key; and,

· Unencrypted email containing sensitive information is accidently/intentionally transmitted or received.

2) All sensitive incident-related information shall be encrypted at all times.

22 NIST SP 800-52 Guidelines for the Selection, Configuration, and Use of Transport Layer Security (TLS) Implementations, http://csrc.nist.gov/publications/PubsSPs.html.

23 OMB M-15-13.

24HHS Acquisition Policies and Guidance Portal, available at: http://intranet.hhs.gov/abouthhs/contracts-grants- support/acquisition/.

25 HHS Computer Security Incident Response Center (CSIRC), http://intranet.hhs.gov/it/cybersecurity/hhs_csirc/index.html.

1.6 Deviations

1) All deviations from these standards must be documented using a risk-based decision and/or waiver request and submitted to and approved by the OpDiv CISO. Documentation must state a business need for the deviation and the compensating security controls implemented to secure the device and/or information.

2) If government data on mobile computers/devices is determined to be non-sensitive and does not require encryption, determination shall be done in writing by the business/data owner and approved by the OpDiv CISO or Senior Official for Privacy (SOP).26

26 OMB M-06-16 Protection of Sensitive Agency Information, https://www.whitehouse.gov/sites/default/files/omb/assets/omb/memoranda/fy2006/m06-16.pdf.

2. Roles and Responsibilities

The following are specific roles and responsibilities applicable to this Standard:

1) The HHS CISO shall oversee the implementation and manage the overarching HHS policy and standard for the encryption of sensitive data and devices to ensure compliance with the Federal Information Security Modernization Act of 2014 (FISMA), OMB directive, and other federal requirements. This includes deploying effective security controls to provide Federal employees and contractors with multifactor authentication, digital signature, and encryption capabilities that are interoperable, accepted government-wide, and provide assurance of identity.27

2) The HHS SAOP shall oversee, coordinate, and facilitate the implementation and manage the overarching HHS policy and standard for the encryption of sensitive PII to ensure compliance with the FISMA, OMB directive, and other federal requirements. This includes deploying the privacy controls required by NIST SP 800-53 as amended.

3) OpDiv Chief Information Officers (CIOs) shall ensure compliant encryption tools are available to all users and encryption technologies are integrated into programming/planning/budgeting cycles, enterprise architectures, and acquisition/system development life cycles.

4) OpDiv CISOs shall ensure the HHS encryption policy and standards are appropriately implemented, managed, and monitored across the OpDiv, including field and regional offices, to ensure their effectiveness.

5) The OpDiv SOP shall ensure that Departmental encryption policies and standards are implemented and that encryption capabilities to encrypt sensitive PII are available.

6) OpDiv IT and cybersecurity professionals shall implement encryption standards and solutions in accordance with HHS policy and this standard.

7) System and information owners shall establish business processes to ensure encryption requirements for processing, storage, and backup of sensitive information are implemented, including but not limited to:

· Providing protected storage areas and access controls for business users (e.g., restricting shared drives to least privilege access and only allow access to those who need to know).

· Ensuring business users have the tools, technologies, and protocols they need to remain compliant with encryption policy.

· Ensuring training is provided to general users to encrypt data at rest and in transit.

8) General Users shall:

· Encrypt HHS sensitive data (sensitive PII, PHI, etc.) at rest (e.g. in folders and files) and in transit [e.g., mobile devices, email and attachments (transmitted both internally and externally)].

27 The OMB Circular A-130, https://www.whitehouse.gov/omb/circulars_a130_a130trans4.

· Not use external drives unless they are government approved, encrypted and have been inventoried (i.e., not shadow IT).

· Restrict encrypted data on HHS shared drives to “need to know.” Use the individual network drive for storing HHS information.28

· Only use encrypted devices provided by the government for processing and storing HHS sensitive information and when on foreign travel.

28 It is not recommended to store data on GFE’s c: drive.

NIH CC Policy for Remote Access to IT & Medical Systems xii

[Page intentionally left blank] iii

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…