Attachment A- .gov TLD Registry and DNS Services Statement of Objectives.pdf

.gov Top Level Domain (TLD) Registry and DNS Services in support of:

Cybersecurity and Infrastructure Security Agency (CISA)

DRAFT

1.0 Background

The Cybersecurity and Infrastructure Security Agency (CISA) is the Nation’s risk advisor, working with partners to defend against today’s threats and collaborating to build more secure and resilient infrastructure for the future. In this role, CISA builds the nation’s capacity to defend against cyber attacks by providing cybersecurity tools, incident response capabilities, and assessment services to safeguard the Federal IT enterprise, state and local partners, and systems that support national critical functions.

The DOTGOV Act of 2020, appointed CISA as the policy and management authority for the

.gov TLD. .gov domains (e.g., whitehouse.gov) are only available to bona fide U.S.-based government organizations and publicly controlled entities. Since they signal being official and trusted, .gov domains are actively used by each branch of the federal government, every state in the nation, hundreds of counties and cities, and many tribes and territories to serve the public on the internet. The .gov zone currently includes 7300 domains, and CISA anticipates consistent growth (+20% yearly) over the next few years.

The .gov TLD is central to the availability and integrity of thousands of online services relied upon by millions of users, and thus the .gov is considered critical infrastructure for governments throughout the country.

2.0 Purpose

The purpose of this contract is to provide CISA with a registry services provider that can meet the .gov registry’s need for highly available DNS services that enhance resilience and simplify security operations for .gov domain users. CISA makes .gov domains available at no cost to bona fide US-based government organizations, but it takes more than registering a domain to put it on the internet. It requires the name be hosted by a DNS nameserver that is authoritative for the domain.

At present, the .gov TLD does not offer authoritative DNS hosting. This means that even though a .gov domain is free, staff at government organizations must manage their own DNS servers or procure access to a DNS service in order to use their domain. This increases a financial and technical burden, which is felt most acutely in non-federal government organizations, disincentivizing a move to .gov.

Additionally, the absence of a central DNS hosting offering produces at least three negative security outcomes for CISA:

1. Wider attack surface: Registrants host their DNS with many different service providers, and these providers vary widely in the usability and security of their services. This vastly increases the attack surface of .gov-related infrastructure and government organizations.

2. Weak defaults: Individual management of authoritative DNS leads to suboptimal namespace-wide security. A central offering would allow CISA to automate sensitive portions of DNS security management, set DNS records that make it hard to successfully impersonate government in email by default, and offer new features that typically require coordination between various parties.

3. Lack of visibility: With a central DNS hosting service, CISA could better detect and prevent certain DNS ecosystem issues instead of reacting to them (see Emergency

Directive 19-01). With DNS hosting for .gov domains spread across the internet, CISA also lacks direct insight into the subdomains and hostnames operating on a .gov domain.

This requires the agency to collate the names of online services that use .gov in piecemeal fashion, something that would largely be obtained natively through the offering of a central service.

DNS is a core internet service that is foundational to the security of the applications that sit on top of it. Expanding the .gov TLD to include authoritative DNS hosting allows CISA to minimize the attack surface for .gov and using organizations, ensure a strong security baseline to governments, and increase insight into potential security issues. It also makes .gov more attractive to governments since they can manage their organization’s namespace in one place.

CISA is concurrently developing a domain name registrar, separately from this contract, that will be the interface for administrators of .gov domains to interface the registry provider’s services

3.0 Scope

The scope of this contract is to provide CISA and participating .gov domain users, access to .gov

TLD registry and DNS services. The service provided shall include managed nameservers for the

.gov zone and authoritative DNS hosting for .gov domain names. The .gov TLD registry and

DNS services are available to all bona fide U.S.-based government organizations and publicly controlled entities.

The registry services provider shall provide the Government with project management support, expert-level consultation services, and ensure the services are effectively secured during the entire period of performance. In addition, the registry services provider shall provide all other core registry services needed to support the service in operation.

4.0 Performance Objectives

The following subsections provide the technical objectives for the registry service. CISA envisions an iterative approach to satisfying all requirements. The initial deployed solution shall include, at a minimum, all targeted requirements addressed in the following objectives.

4.1 Operate Secure and Resilient Authoritative Nameservers

The registry services provider shall operate secure and resilient authoritative nameservers to serve the .gov zone file in IPv4/v6, ensuring global, always-available DNS resolution with low latency (100% uptime and availability). The average query load is currently between 10 and 20 billion queries per month.

DRAFT

https://cyber.dhs.gov/ed/19-01/ https://cyber.dhs.gov/ed/19-01/

The performance objectives of authoritative nameservers service shall include, but not be limited to, the following:

a. Performantly respond to queries despite failures (e.g., hardware, software, networking), attacks (e.g., distributed denial of service), or accidents (e.g., vulnerabilities).

b. Maintain the .gov zone file, sourcing updates from the .gov registrar, via Extensible

Provisioning Protocol or other means. After registry policies are met (e.g., a new domain is approved and nameservers are responsive with proper resource records; a domain is to be placed on serverHold for non-compliance determined by CISA), updates to the .gov zone must be near-real-time.

c. Sign and manage DNS Security Extensions (DNSSEC) for the TLD.

d. Align with applicable Internet Engineering Task Force Request for Comments to ensure utility and interoperability.

e. In ICANN’s Base Registry Agreement (or successor document):

i. Align with the Specification 6, Registry Interoperability and Continuity

Specifications, sections 1-3.

ii. Meet or exceed the service level requirements in Specification 10, Registry

Performance Specifications for offered protocols.

4.2 Operate, Secure, and Offer Authoritative DNS Hosting for Registered .gov Domains

The registry services provider shall operate, secure, and offer authoritative DNS hosting for registered .gov domains and child zones in IPv4/v6, served from multiple networks and geographic locations to support 100% uptime and availability across the internet with low latency. Average query load will vary between types and sizes of government organizations.

Some primary domains for major federal agencies see 5-20 billion queries per month.

The performance objectives of authoritative DNS hosting service shall include, but not be limited to, the following:

a. Enable management of DNS resources via well-documented API. CISA will use the provider’s DNS hosting APIs to expose a “zone template” to registrants through the .gov registrar (with values they can modify).

b. The provider must support an infrastructure-as-code approach (e.g., Terraform) to domain management.

c. The service must support common resource records (e.g., SOA, NS, A, CNAME, MX, TXT, PTR, DNAME), DNSSEC RRs (e.g., DNSKEY, DS, NSEC3), useful/emerging

RRs (e.g., CSYNC, CDS, CDNSKEY, TLSA, HTTPS) and quasi-record functionality

(e.g., ALIAS) with tunable values (e.g., TTL).

d. Updates to the DNS hosting service (e.g., publication of new or updated resource records) must be near-real-time.

e. Use of the DNS hosting service will not be mandatory on registrants, and they may elect to manage their own DNS or use a third-party service. These registrants may elect to use the DNS hosting offering as secondary/tertiary authoritative service in order to increase resilience.

https://www.icann.org/en/registry-agreements/base-agreement

f. In addition to hosting .gov domains, DNS hosting must be available to non-.gov domains

– after approval by CISA in the .gov registrar – that government orgs manage in other registrars. (In time, CISA anticipates the ability to transfer non-.gov domain name into the .gov registrar directly.)

g. CISA seeks offer new DNS features as they offer utility to our users or public users, like authoritative-to-recursive transit encryption.

h. In order to minimize the impact of a critical vulnerability across hosted zones, CISA is interested in DNS nameserver software diversity.

4.3 Provide Registry Support Services

The registry services provider shall provide all necessary support services to ensure the registry service is managed and supported effectively throughout the period of performance. The following subsections address required service areas.

4.3.1 Provide Project Management Support

The registry services provider shall provide project management services under this contract that support the successful implementation and operation of the registry service. The management services include the management and oversight of all activities performed by service provider personnel, including subcontractors, to satisfy the requirements of this contract.

Performance objectives for the project management support include, but are not limited to the following:

a. Perform management functions.

b. Conduct a project kickoff meeting.

c. Develop and submit monthly status reports that captures:

a. Activities during a reporting period

b. Milestone planning and tracking

c. Financial management aspects including funding and all incurred costs

d. Support an ad-hoc meeting request as needed.

e. Perform a seamless transition from the incumbent registry services provider (as necessary).

f. Ensure a seamless transition out at the end of the period of performance.

4.3.2 Provide Expert-Level Consultation

The registry services provider shall provide expert-level consultation on the DNS ecosystem to assist CISA in ensuring the DNS service is useful, and operated with “transparently and in the spirit of public accessibility, privacy, and security” as required by the DOTGOV Act.

Performance objectives for the expert-level consultation include, but are not limited to the following:

a. Provide consulting support on the new .gov registrar, including ability for the registry service provider’s solution to integrate with the new registrar.

b. Provide strategic and tactical planning, advise on DNS best practices and opportunities, and collaborate to devise technical solutions to emerging challenges.

c. Assist in the development of roadmaps, plans and technical briefing materials as needed.

4.3.3 Support Core Registry Services

The registry services provider shall support other core registry services as needed.

Performance objectives include, but are not limited to, the following:

a. Providing “Tier 3”, 24x7 engineering support to CISA to remedy operational issues or incidents related to the registry or DNS hosting.

b. Manage registration data directory services: Registration Data Access Protocol (RDAP), WHOIS, while meeting or exceeding the service level requirements in ICANN’s Base

Registry Agreement (or successor document), Specification 10, Registry Performance

Specifications for offered protocols.

c. Track useful performance metrics and trends for the .gov zone and domains (e.g., query load) and make them available programmatically through operational reports.

4.3.4 Secure Registry Services

The registry is anticipated to be a FIPS 199 high impact system and a high value asset. The provider will ensure their services are secured, receives an “authority to operate” (ATO) from the

CISA CIO, and maintains that ATO throughout the period of performance. This will include a major role in the preparation of privacy/security documentation required by federal law or agency policy, and technical alignment with those requirements. It will include the preparation/maintenance of documents like a system security plan, contingency plan, incident response plan, privacy threshold analysis or impact assessment, rules of behavior.

Performance objectives including, but are not limited to, the following:

a. Obtain ATO from CISA as soon as possible following contract award.

b. Submission of all necessary security authorization documentation

c. Maintaining ATO (following receipt) during complete period of performance, including updating relevant security authorization documentation as needed.

5.0 Constraints

CISA has identified the following operational constraints to this effort:

a. CISA is building a new .gov registrar to enable US-based government organizations to manage their domain’s registration lifecycle, DNS settings, and useful supporting services. Key DNS functionality for the registrar will be enabled by integration with the service provider’s application programming interfaces (APIs).

b. Given its unique role, .gov requires a provider that is incorporated or legally organized under the laws of the United States whose core competency is DNS services.

DRAFT

https://www.icann.org/en/registry-agreements/base-agreement https://www.icann.org/en/registry-agreements/base-agreement https://www.whitehouse.gov/sites/whitehouse.gov/files/omb/memoranda/2017/m-17-09.pdf

c. CISA anticipates the services to be in scope of our vulnerability disclosure policy, as required by Binding Operational Directive 20-01.

6.0 Contract Deliverables

The following abbreviations are used in this schedule:

DEL: Deliverable

All references to days: Government Workdays

Deliverables are due the next Government workday if the due date falls on a holiday or weekend.

The service provider shall deliver the deliverables listed in the following table on the dates specified:

The contractor shall deliver all electronic versions by electronic mail (email) and removable electronic media, as well as placing in DHS’ designated repository. The following are the required electronic formats, whose versions must be compatible with the latest, commonly available version on the market.

a. Text Microsoft (MS) Word, PDF

b. Spreadsheets MS Excel

c. Briefings MS PowerPoint

d. Drawings MS Visio

e. Schedules MS Project

7.0 Quality Assurance and Acceptable Criteria

The Government has established and will maintain a Quality Assurance Surveillance Plan

(QASP) for work accomplished under this contract. The QASP will be based under the following standards and acceptable quality levels (AQL)s:

DEL. # DELIVERABLE DUE DATE

01 Kick-Off Meeting Within 10 workdays of contract award

02 Monthly Status Reporting Within 10 workdays after beginning of month

03 Operational Reports Within 10 workdays after beginning of month

Security Authorization

Documentation

Initial as soon as possible following award, updates as needed to maintain the ATO

Deliverable or

Service

Performance Standard Acceptable Quality Level

Operate Secure and

Resilient

Authoritative

Nameservers

SLA's identified in

ICANN's Base Registry

Agreement Specification

10, Registry Performance

Specifications

Meet or exceed SLA's for any offered protocol.

Operate Secure and

Resilient

Authoritative

Nameservers

Operational uptime and availability 100% Uptime and 100% Availability

Operate Authoritative

DNS Hosting for

Registered .gov

Domains

Operational uptime and availability 100% Uptime and 100% Availability

WHOIS

SLA's identified in

ICANN's Base Registry

Agreement Specification

10, Registry Performance

Specifications

Meet or exceed SLA's for any offered protocol.

Operational Reports

Tailored operational reports are delivered on time and effectively tailored to address the stakeholder needs

100% of reports submitted on time, effectiveness of operational reports assessed in on-going manner with consistent feedback

8.0 Period and Place of Performance

The period of performance for this contract is a 12-month base period followed by four, 12-month option periods.

The primary place of performance will be at the contractor’s site. The solution shall be available to support US Government operations domestically and internationally.

9.0 Key Personnel

The following are the minimum personnel who shall be designated as “Key.”.

All requirements of the contractor apply equally to any proposed additional Key Personnel.

a. Project Manager (PM)

The Government desires that Key Personnel be assigned for the duration of the TO. Key

Personnel may be replaced or removed subject to Section 9.2, Key Personnel Substitution.

9.1 Project Manager

The service provider shall identify a PM to serve as the Government’s main point-of-contact and to provide overall leadership and guidance for all service provider personnel assigned to the contract. The PM shall ultimately be responsible for the quality and efficiency of the work performed under this contract. The PM shall have organizational authority to execute the requirements of the contract. The PM shall assign tasking to service provider personnel, supervise ongoing technical efforts, and manage overall performance to ensure the optimal use of assigned resources and subcontractors. This Key Person shall have the ultimate authority to commit the service provider’s organization and make decisions for the service provider’s organization in response to Government issues, concerns, or problems. The PM shall be readily available to respond to Government questions, concerns, and comments, as well as be proactive in alerting the Government to potential contractual and programmatic issues.

It is desirable that the PM possess the following qualifications:

a. Experience in completing, leading, or directing the work of others on projects similar to the size, scope, and complexity of the work and environment described in Section 4.

b. Managerial experience providing technical advice, organizing, planning, directing, and managing staff to ensure goals and objectives are achieved.

c. Experience with the management and supervision of teams comprised of technical multi-discipline employees and teaming partners/subcontractors.

d. Experience with risk management, issue resolution, problem solving, and customer service.

9.2 Key Personnel Substitution

The service provider shall not replace any personnel designated as Key Personnel without the written concurrence of the CO. Prior to using other than personnel specified in proposals, the service provider shall notify the CO and the COR. This notification shall be NLT ten calendar days in advance of any proposed substitution and shall include justification for the proposed substitution, resume, and labor category of proposed substitution in sufficient detail to permit evaluation of the impact on performance.

10.0 Special Contract Requirements

10.1 Security Requirements

10.1.1 Security References

• DHS Management Directive 140-01, “Information Technology Security Program

• DHS National Security Systems Policy Directive 4300A, (Version 13.1, July 25, 2017) and DHS 4300A Sensitive Systems Handbook (Version 12.0, November 15, 2015)

• DHS National Security Systems Policy Directive 4300B, Version 10.1, November 21, 2018’ for NSS Collateral (Unclass, Secret or Top Secret Collateral).

• ‘DHS Sensitive Compartmented Information (SCI) Systems 4300C Instruction Manual, Version 2.1, March 24, 2017’ for TS SCI/C-LAN.

10.1.2 Security Requirements

SAFEGUARDING OF SENSITIVE INFORMATION (MAR 2015)

(a) Applicability. This clause applies to the Contractor, its subcontractors, and Contractor employees (hereafter referred to collectively as “Contractor”). The Contractor shall insert the substance of this clause in all subcontracts.

(b) Definitions. As used in this clause—

“Personally Identifiable Information (PII)” means information that can be used to distinguish or trace an individual's identity, such as name, social security number, or biometric records, either alone, or when combined with other personal or identifying information that is linked or linkable to a specific individual, such as date and place of birth, or mother’s maiden name. The definition of PII is not anchored to any single category of information or technology. Rather, it requires a case-by-case assessment of the specific risk that an individual can be identified. In performing this assessment, it is important for an agency to recognize that non-personally identifiable information can become personally identifiable information whenever additional information is made publicly available—in any medium and from any source—that, combined with other available information, could be used to identify an individual.

PII is a subset of sensitive information. Examples of PII include, but are not limited to: name, date of birth, mailing address, telephone number, Social Security number (SSN), email address, zip code, account numbers, certificate/license numbers, vehicle identifiers including license plates, uniform resource locators (URLs), static Internet protocol addresses, biometric identifiers such as fingerprint, voiceprint, iris scan, photographic facial images, or any other unique identifying number or characteristic, and any information where it is reasonably foreseeable that the information will be linked with other information to identify the individual.

“Sensitive Information” is defined in HSAR clause 3052.204-71, Contractor Employee Access, as any information, which if lost, misused, disclosed, or, without authorization is accessed, or modified, could adversely affect the national or homeland security interest, the conduct of

Federal programs, or the privacy to which individuals are entitled under section 552a of Title 5, United States Code (the Privacy Act), but which has not been specifically authorized under criteria established by an Executive Order or an Act of Congress to be kept secret in the interest of national defense, homeland security or foreign policy. This definition includes the following categories of information:

(1) Protected Critical Infrastructure Information (PCII) as set out in the Critical Infrastructure

Information Act of 2002 (Title II, Subtitle B, of the Homeland Security Act, Public Law 107-

296, 196 Stat. 2135), as amended, the implementing regulations thereto (Title 6, Code of Federal

Regulations, Part 29) as amended, the applicable PCII Procedures Manual, as amended, and any supplementary guidance officially communicated by an authorized official of the Department of

Homeland Security (including the PCII Program Manager or his/her designee);

(2) Sensitive Security Information (SSI), as defined in Title 49, Code of Federal Regulations, Part 1520, as amended, “Policies and Procedures of Safeguarding and Control of SSI,” as amended, and any supplementary guidance officially communicated by an authorized official of the Department of Homeland Security (including the Assistant Secretary for the Transportation

Security Administration or his/her designee);

(3) Information designated as “For Official Use Only,” which is unclassified information of a sensitive nature and the unauthorized disclosure of which could adversely impact a person’s privacy or welfare, the conduct of Federal programs, or other programs or operations essential to the national or homeland security interest; and

(4) Any information that is designated “sensitive” or subject to other controls, safeguards or protections in accordance with subsequently adopted homeland security information handling procedures.

“Sensitive Information Incident” is an incident that includes the known, potential, or suspected exposure, loss of control, compromise, unauthorized disclosure, unauthorized acquisition, or unauthorized access or attempted access of any Government system, Contractor system, or sensitive information.

“Sensitive Personally Identifiable Information (SPII)” is a subset of PII, which if lost, compromised or disclosed without authorization, could result in substantial harm, embarrassment, inconvenience, or unfairness to an individual. Some forms of PII are sensitive as stand-alone elements. Examples of such PII include: Social Security numbers (SSN), driver’s license or state identification number, Alien Registration Numbers (A-number), financial account number, and biometric identifiers such as fingerprint, voiceprint, or iris scan. Additional examples include any groupings of information that contain an individual’s name or other unique identifier plus one or more of the following elements:

(1) Truncated SSN (such as last 4 digits)

(2) Date of birth (month, day, and year)

(3) Citizenship or immigration status

(4) Ethnic or religious affiliation

(5) Sexual orientation

(6) Criminal History

(7) Medical Information

(8) System authentication information such as mother’s maiden name, account passwords or personal identification numbers (PIN)

Other PII may be “sensitive” depending on its context, such as a list of employees and their performance ratings or an unlisted home address or phone number. In contrast, a business card or public telephone directory of agency employees contains PII but is not sensitive.

(c) Authorities. The Contractor shall follow all current versions of Government policies and guidance accessible at http://www.dhs.gov/dhs-security-and-training-requirements-contractors, or available upon request from the Contracting Officer, including but not limited to:

(1) DHS Management Directive 11042.1 Safeguarding Sensitive But Unclassified (for

Official Use Only) Information

(2) DHS Sensitive Systems Policy Directive 4300A

(3) DHS 4300A Sensitive Systems Handbook and Attachments

(4) DHS Security Authorization Process Guide

(5) DHS Handbook for Safeguarding Sensitive Personally Identifiable Information

(6) DHS Instruction Handbook 121-01-007 Department of Homeland Security Personnel

Suitability and Security Program

(7) DHS Information Security Performance Plan (current fiscal year)

(8) DHS Privacy Incident Handling Guidance

(9) Federal Information Processing Standard (FIPS) 140-2 Security Requirements for

Cryptographic Modules accessible at http://csrc.nist.gov/groups/STM/cmvp/standards.html

(10) National Institute of Standards and Technology (NIST) Special Publication 800-53

Security and Privacy Controls for Federal Information Systems and Organizations accessible at http://csrc.nist.gov/publications/PubsSPs.html

(11) NIST Special Publication 800-88 Guidelines for Media Sanitization accessible at http://csrc.nist.gov/publications/PubsSPs.html

(d) Handling of Sensitive Information. Contractor compliance with this clause, as well as the policies and procedures described below, is required.

(1) Department of Homeland Security (DHS) policies and procedures on Contractor personnel security requirements are set forth in various Management Directives (MDs), Directives, and

Instructions. MD 11042.1, Safeguarding Sensitive But Unclassified (For Official Use Only)

Information describes how Contractors must handle sensitive but unclassified information. DHS uses the term “FOR OFFICIAL USE ONLY” to identify sensitive but unclassified information that is not otherwise categorized by statute or regulation. Examples of sensitive information that are categorized by statute or regulation are PCII, SSI, etc. DHS Sensitive Systems Policy

Direction 4300A Version 13.1, July 27, 2017 provide the policies and procedures on security for

Information Technology (IT) resources. The DHS Handbook for Safeguarding Sensitive

Personally Identifiable Information provides guidelines to help safeguard SPII in both paper and

DRAFT

http://www.dhs.gov/dhs-security-and-training-requirements-contractors http://csrc.nist.gov/publications/PubsSPs.html electronic form. DHS Instruction Handbook 121-01-007 Department of Homeland Security

Personnel Suitability and Security Program establishes procedures, program responsibilities, minimum standards, and reporting protocols for the DHS Personnel Suitability and Security

Program.

(2) The Contractor shall not use or redistribute any sensitive information processed, stored, and/or transmitted by the Contractor except as specified in the contract.

(3) All Contractor employees with access to sensitive information shall execute DHS Form

11000-6, Department of Homeland Security Non-Disclosure Agreement (NDA), as a condition of access to such information. The Contractor shall maintain signed copies of the NDA for all employees as a record of compliance. The Contractor shall provide copies of the signed NDA to the Contracting Officer’s Representative (COR) no later than two (2) days after execution of the form.

(4) The Contractor’s invoicing, billing, and other recordkeeping systems maintained to support financial or other administrative functions shall not maintain SPII. It is acceptable to maintain in these systems the names, titles and contact information for the COR or other Government personnel associated with the administration of the contract, as needed.

(e) Authority to Operate. The Contractor shall not input, store, process, output, and/or transmit sensitive information within a Contractor IT system without an Authority to Operate (ATO) signed by the Headquarters or Component CIO, or designee, in consultation with the

Headquarters or Component Privacy Officer. Unless otherwise specified in the ATO letter, the

ATO is valid for three (3) years. The Contractor shall adhere to current Government policies, procedures, and guidance for the Security Authorization (SA) process as defined below.

(i) COMPLETE THE SECURITY AUTHORIZATION PROCESS. THE SA PROCESS SHALL

PROCEED ACCORDING TO THE DHS SENSITIVE SYSTEMS POLICY DIRECTIVE

4300A: (VERSION 13.1, JULY 27, 2017), OR ANY SUCCESSOR PUBLICATION, DHS 4300A

SENSITIVE SYSTEMS HANDBOOK (VERSION 12.0, NOVEMBER 15, 2015), OR ANY SUCCESSOR

PUBLICATION, AND THE SECURITY AUTHORIZATION PROCESS GUIDE INCLUDING

TEMPLATES.

(ii) Security Authorization Process Documentation. SA documentation shall be developed using the Government provided Requirements Traceability Matrix and Government security documentation templates. SA documentation consists of the following: Security Plan, Contingency Plan, Contingency Plan Test Results, Configuration Management Plan, Security

Assessment Plan, Security Assessment Report, and Authorization to Operate Letter.

Additional documents that may be required include a Plan(s) of Action and Milestones and

Interconnection Security Agreement(s). During the development of SA documentation, the

Contractor shall submit a signed SA package, validated by an independent third party, to the

COR for acceptance by the Headquarters or Component CIO, or designee, at least thirty (30) days prior to the date of operation of the IT system. The Government is the final authority on the compliance of the SA package and may limit the number of resubmissions of a modified

SA package. Once the ATO has been accepted by the Headquarters or Component CIO, or designee, the Contracting Officer shall incorporate the ATO into the contract as a compliance document. The Government’s acceptance of the ATO does not alleviate the Contractor’s responsibility to ensure the IT system controls are implemented and operating effectively.

(iii) Independent Assessment. Contractors shall have an independent third party validate the security and privacy controls in place for the system(s). The independent third party shall review and analyze the SA package, and report on technical, operational, and management level deficiencies as outlined in NIST Special Publication 800-53 Security and Privacy

Controls for Federal Information Systems and Organizations. The Contractor shall address all deficiencies before submitting the SA package to the Government for acceptance.

(iv) Support the completion of the Privacy Threshold Analysis (PTA) as needed. As part of the SA process, the Contractor may be required to support the Government in the completion of the PTA. The requirement to complete a PTA is triggered by the creation, use, modification, upgrade, or disposition of a Contractor IT system that will store, maintain and use PII, and must be renewed at least every three (3) years. Upon review of the PTA, the

DHS Privacy Office determines whether a Privacy Impact Assessment (PIA) and/or Privacy

Act System of Records Notice (SORN), or modifications thereto, are required. The

Contractor shall provide all support necessary to assist the Department in completing the PIA in a timely manner and shall ensure that project management plans and schedules include time for the completion of the PTA, PIA, and SORN (to the extent required) as milestones.

Support in this context includes responding timely to requests for information from the

Government about the use, access, storage, and maintenance of PII on the Contractor’s system, and providing timely review of relevant compliance documents for factual accuracy.

Information on the DHS privacy compliance process, including PTAs, PIAs, and SORNs, is accessible at http://www.dhs.gov/privacy-compliance.

(2) Renewal of ATO. Unless otherwise specified in the ATO letter, the ATO shall be renewed every three (3) years. The Contractor is required to update its SA package as part of the ATO renewal process. The Contractor shall update its SA package by one of the following methods:

(1) Updating the SA documentation in the DHS automated information assurance tool for acceptance by the Headquarters or Component CIO, or designee, at least 90 days before the ATO expiration date for review and verification of security controls; or (2) Submitting an updated SA package directly to the COR for approval by the Headquarters or Component CIO, or designee, at least 90 days before the ATO expiration date for review and verification of security controls.

The 90 day review process is independent of the system production date and therefore it is important that the Contractor build the review into project schedules. The reviews may include onsite visits that involve physical or logical inspection of the Contractor environment to ensure controls are in place.

(3) Security Review. The Government may elect to conduct random periodic reviews to ensure that the security requirements contained in this contract are being implemented and enforced.

The Contractor shall afford DHS, the Office of the Inspector General, and other Government organizations access to the Contractor’s facilities, installations, operations, documentation, databases and personnel used in the performance of this contract. The Contractor shall, through the Contracting Officer and COR, contact the Headquarters or Component CIO, or designee, to coordinate and participate in review and inspection activity by Government organizations external to the DHS. Access shall be provided, to the extent necessary as determined by the

Government, for the Government to carry out a program of inspection, investigation, and audit to safeguard against threats and hazards to the integrity, availability and confidentiality of

Government data or the function of computer systems used in performance of this contract and to preserve evidence of computer crime.

(4) Continuous Monitoring. All Contractor-operated systems that input, store, process, output, and/or transmit sensitive information shall meet or exceed the continuous monitoring requirements identified in the Fiscal Year 2014 DHS Information Security Performance Plan, or successor publication. The plan is updated on an annual basis. The Contractor shall also store monthly continuous monitoring data at its location for a period not less than one year from the date the data is created. The data shall be encrypted in accordance with FIPS 140-2 Security

Requirements for Cryptographic Modules and shall not be stored on systems that are shared with other commercial or Government entities. The Government may elect to perform continuous monitoring and IT security scanning of Contractor systems from Government tools and infrastructure.

(5) Revocation of ATO. In the event of a sensitive information incident, the Government may suspend or revoke an existing ATO (either in part or in whole). If an ATO is suspended or revoked in accordance with this provision, the Contracting Officer may direct the Contractor to take additional security measures to secure sensitive information. These measures may include restricting access to sensitive information on the Contractor IT system under this contract. Restricting access may include disconnecting the system processing, storing, or transmitting the sensitive information from the Internet or other networks or applying additional security controls.

(6) Federal Reporting Requirements. Contractors operating information systems on behalf of the

Government or operating systems containing sensitive information shall comply with Federal reporting requirements. Annual and quarterly data collection will be coordinated by the

Government. Contractors shall provide the COR with requested information within three (3) business days of receipt of the request. Reporting requirements are determined by the

Government and are defined in the Fiscal Year 2014 DHS Information Security Performance

Plan, or successor publication. The Contractor shall provide the Government with all information to fully satisfy Federal reporting requirements for Contractor systems.

(f) Sensitive Information Incident Reporting Requirements.

(1) All known or suspected sensitive information incidents shall be reported to the Headquarters or Component Security Operations Center (SOC) within one hour of discovery in accordance with 4300A Sensitive Systems Handbook Incident Response and Reporting requirements. When notifying the Headquarters or Component SOC, the Contractor shall also notify the Contracting

Officer, COR, Headquarters or Component Privacy Officer, and US-CERT using the contact information identified in the contract. If the incident is reported by phone or the Contracting

Officer’s email address is not immediately available, the Contractor shall contact the Contracting

Officer immediately after reporting the incident to the Headquarters or Component SOC. The

Contractor shall not include any sensitive information in the subject or body of any e-mail. To transmit sensitive information, the Contractor shall use FIPS 140-2 Security Requirements for

Cryptographic Modules compliant encryption methods to protect sensitive information in attachments to email. Passwords shall not be communicated in the same email as the attachment.

A sensitive information incident shall not, by itself, be interpreted as evidence that the Contractor has failed to provide adequate information security safeguards for sensitive information, or has otherwise failed to meet the requirements of the contract.

(2) If a sensitive information incident involves PII or SPII, in addition to the reporting requirements in 4300A Sensitive Systems Handbook Incident Response and Reporting, Contractors shall also provide as many of the following data elements that are available at the time the incident is reported, with any remaining data elements provided within 24 hours of submission of the initial incident report:

(i) Data Universal Numbering System (DUNS);

(ii) Contract numbers affected unless all contracts by the company are affected;

(iii) Facility CAGE code if the location of the event is different than the prime contractor location;

(iv) Point of contact (POC) if different than the POC recorded in the System for Award

Management (address, position, telephone, email);

(v) Contracting Officer POC (address, telephone, email);

(vi) Contract clearance level;

(vii) Name of subcontractor and CAGE code if this was an incident on a subcontractor network;

(viii) Government programs, platforms or systems involved;

(ix) Location(s) of incident;

(x) Date and time the incident was discovered;

(xi) Server names where sensitive information resided at the time of the incident, both at the

Contractor and subcontractor level;

(xii) Description of the Government PII and/or SPII contained within the system;

(xiii) Number of people potentially affected and the estimate or actual number of records exposed and/or contained within the system; and

(xiv) Any additional information relevant to the incident.

(g) Sensitive Information Incident Response Requirements.

(1) All determinations related to sensitive information incidents, including response activities, notifications to affected individuals and/or Federal agencies, and related services (e.g., credit monitoring) will be made in writing by the Contracting Officer in consultation with the

Headquarters or Component CIO and Headquarters or Component Privacy Officer.

(2) The Contractor 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.

(3) Incident response activities determined to be required by the Government may include, but are not limited to, the following:

(i) Inspections,

(ii) Investigations,

(iii) Forensic reviews, and

(iv) Data analyses and processing.

(4) The Government, at its sole discretion, may obtain the assistance from other Federal agencies and/or third-party firms to aid in incident response activities.

(h) Additional PII and/or SPII Notification Requirements.

(1) The Contractor shall have in place procedures and the capability to notify any individual whose PII resided in the Contractor IT system at the time of the sensitive information incident not later than 5 business days after being directed to notify individuals, unless otherwise approved by the Contracting Officer. The method and content of any notification by the

Contractor shall be coordinated with, and subject to prior written approval by the Contracting

Officer, in consultation with the Headquarters or Component Privacy Officer, utilizing the DHS

Privacy Incident Handling Guidance. The Contractor shall not proceed with notification unless the Contracting Officer, in consultation with the Headquarters or Component Privacy Officer, has determined in writing that notification is appropriate.

(2) Subject to Government analysis of the incident and the terms of its instructions to the

Contractor regarding any resulting notification, the notification method may consist of letters to affected individuals sent by first class mail, electronic means, or general public notice, as approved by the Government. Notification may require the Contractor’s use of address verification and/or address location services. At a minimum, the notification shall include:

(i) A brief description of the incident;

(ii) A description of the types of PII and SPII involved;

(iii) A statement as to whether the PII or SPII was encrypted or protected by other means;

(iv) Steps individuals may take to protect themselves;

(v) What the Contractor and/or the Government are doing to investigate the incident, to mitigate the incident, and to protect against any future incidents; and

(vi) Information identifying who individuals may contact for additional information.

(i) Credit Monitoring Requirements. In the event that a sensitive information incident involves

PII or SPII, the Contractor may be required to, as directed by the Contracting Officer:

(1) Provide notification to affected individuals as described above; and/or

(2) Provide credit monitoring services to individuals whose data was under the control of the

Contractor or resided in the Contractor IT system at the time of the sensitive information incident for a period beginning the date of the incident and extending not less than 18 months from the date the individual is notified. Credit monitoring services shall be provided from a company with which the Contractor has no affiliation. At a minimum, credit monitoring services shall include:

(i) Triple credit bureau monitoring;

(ii) Daily customer service;

(iii) Alerts provided to the individual for changes and fraud; and

(iv) Assistance to the individual with enrollment in the services and the use of fraud alerts;

and/or

(3) Establish a dedicated call center. Call center services shall include:

(i) A dedicated telephone number to contact customer service within a fixed period;

(ii) Information necessary for registrants/enrollees to access credit reports and credit scores;

(iii) Weekly reports on call center volume, issue escalation (i.e., those calls that cannot be handled by call center staff and must be resolved by call center management or DHS, as appropriate), and other key metrics;

(iv) Escalation of calls that cannot be handled by call center staff to call center management or DHS, as appropriate;

(v) Customized FAQs, approved in writing by the Contracting Officer in coordination with the Headquarters or Component Chief Privacy Officer; and

(vi) Information for registrants to contact customer service representatives and fraud resolution representatives for credit monitoring assistance.

(j) Certification of Sanitization of Government and Government-Activity-Related Files and

Information. As part of contract closeout, the Contractor shall submit the certification to the

COR and the Contracting Officer following the template provided in NIST Special Publication

800-88 Guidelines for Media Sanitization.

INFORMATION SECURITY AND PRIVACY TRAINING (MAR 2015)

(a) Applicability. This clause applies to the Contractor, its subcontractors, and Contractor employees (hereafter referred to collectively as “Contractor”). The Contractor shall insert the substance of this clause in all subcontracts.

(b) Security Training Requirements.

(1) All users of Federal information systems are required by Title 5, Code of Federal

Regulations, Part 930.301, Subpart C, as amended, to be exposed to security awareness materials annually or whenever system security changes occur, or when the user’s responsibilities change.

The Department of Homeland Security (DHS) requires that Contractor employees take an annual

Information Technology Security Awareness Training course before accessing sensitive information under the contract. Unless otherwise specified, the training shall be completed within thirty (30) days of contract award and be completed on an annual basis thereafter not later than October 31st of each year. Any new Contractor employees assigned to the contract shall complete the training before accessing sensitive information under the contract. The training is accessible at http://www.dhs.gov/dhs-security-and-training-requirements-contractors. The

Contractor shall maintain copies of training certificates for all Contractor and subcontractor employees as a record of compliance. Unless otherwise specified, initial training certificates for each Contractor and subcontractor employee shall be provided to the Contracting Officer’s

Representative (COR) not later than thirty (30) days after contract award. Subsequent training certificates to satisfy the annual training requirement shall be submitted to the COR via e-mail notification not later than October 31st of each year. The e-mail notification shall state the required training has been completed for all Contractor and subcontractor employees.

(2) The DHS Rules of Behavior apply to every DHS employee, Contractor and subcontractor that will have access to DHS systems and sensitive information. The DHS Rules of Behavior shall be signed before accessing DHS systems and sensitive information. The DHS Rules of

Behavior is a document that informs users of their responsibilities when accessing DHS systems and holds users accountable for actions taken while accessing DHS systems and using DHS

Information Technology resources capable of inputting, storing, processing, outputting, and/or transmitting sensitive information. The DHS Rules of Behavior is accessible at http://www.dhs.gov/dhs-security-and-training-requirements-contractors. Unless otherwise specified, the DHS Rules of Behavior shall be signed within thirty (30) days of contract award.

Any new Contractor employees assigned to the contract shall also sign the DHS Rules of

Behavior before accessing DHS systems and sensitive information. The Contractor shall maintain signed copies of the DHS Rules of Behavior for all Contractor and subcontractor employees as a record of compliance. Unless otherwise specified, the Contractor shall e-mail copies of the signed DHS Rules of Behavior to the COR not later than thirty (30) days after contract award for each employee. The DHS Rules of Behavior will be reviewed annually and the COR will provide notification when a review is required.

(c) Privacy Training Requirements. All Contractor and subcontractor employees that will have access to Personally Identifiable Information (PII) and/or Sensitive PII (SPII) are required to take

Privacy at DHS: Protecting Personal Information before accessing PII and/or SPII. The training is accessible at http://www.dhs.gov/dhs-security-and-training-requirements-contractors.

Training shall be completed within thirty (30) days of contract award and be completed on an annual basis thereafter not later than October 31st of each year. Any new Contractor employees assigned to the contract shall also complete the training before accessing PII and/or SPII. The

Contractor shall maintain copies of training certificates for all Contractor and subcontractor employees as a record of compliance. Initial training certificates for each Contractor and subcontractor employee shall be provided to the COR not later than thirty (30) days after contract award.