RFP 70RTAC22R00000010 J.2 - PWS.pdf

RFP 70RTAC22R00000010 - Attachment J.2 Performance Work Statement

DEPARTMENT OF HOMELAND SECURITY (DHS)

PERFORMANCE WORK STATEMENT (PWS)

FOR

Hack DHS – Crowdsourced Vulnerability Assessment Services (CVAS)

1.0 GENERAL

1.1 BACKGROUND

In accordance with Public Law 115-390, “SECURE Technology Act”, the Secretary of the Department of Homeland Security (DHS) approved a multi-year program to execute bug bounties using proven crowd-sourced cybersecurity assessment methodologies on December 14, 2021. A bug bounty is a crowd-sourced penetration test, where security researchers are incentivized to find vulnerabilities (bugs) in systems in return for financial payments (bounties).

Bug bounties are tightly controlled and monitored engagements facilitated by a contractor and the DHS Chief Information Security Officer (CISO).

The SECURE Tech Act permits DHS to provide compensation to security researchers who evaluate DHS’s information systems by mimicking malicious behavior. The program draws from industry best practices and on lessons learned from the highly successful “Hack the Pentagon” program at the Department of Defense (DoD). DoD was the first Federal entity to launch this program, however, Bug bounties are commonly used as a best practice in the private sector, e.g., Facebook, Apple, Intel, and Goldman Sachs.

The Hack DHS program has been approved and authorized by the Secretary and DHS needs to procure services in support the program throughout future years. The procured services will assist in proactively protecting DHS’s computer networks and systems that support the mission essential and high valued assets that are critical both for daily business operations and activities.

Maintaining the security and integrity of DHS networks and systems is a matter of national security and requires the continuous proactive activities to identify and remediate vulnerabilities that can be exploited by malicious cyber actors. As part of its responsibility to the public at large, DHS is constantly considering innovative and diverse approaches to meet this goal. To support DHS’s continual efforts to remain at the forefront of rapidly evolving technologies, and to maintain the highest levels of integrity and security required of its IT infrastructure, DHS has identified an emerging need to leverage a diverse pool of innovative information security researchers (herein referred to as “researcher”), via crowdsourcing, for vulnerability discovery, coordination, and disclosure activities.

1.2 SCOPE

The scope of work, under the resulting Indefinite Delivery Indefinite Quantity (IDIQ) contract vehicle, is to conduct crowdsourced vulnerability discovery and disclosure services across the full range of networks, systems, and information systems, including web applications, software, https://usdhs-my.sharepoint.com/personal/amanda_day_hq_dhs_gov/Documents/1%20New%20files%20Oct%202018/VMB/BugBounty_VDP/BB/Budget/SCOPE%20PARAGRAPHS.doc source code, hardware, software-embedded devices, and other technologies as solicited across the DHS Enterprise or other assets as deemed appropriate by the program office.

1.3 OBJECTIVE

To enhance DHS’s cybersecurity posture by leveraging existing commercial crowdsourcing expertise and best practices that are tailored to the Government’s requirements, sensitivities, and mission.

1.4 APPLICABLE DOCUMENTS

1.4.1 Compliance Documents

The following documents provide specifications, standards, or guidelines that must be complied with in order to meet the requirements of this contract:

• SECURE Technology Act, TITLE I:

(https://www.congress.gov/115/plaws/publ390/PLAW-115publ390.pdf)

• DHS Sensitive Systems Policy 4300A, Attachment O (This document will be provided upon contract award)

• S1 signed Action Memo (This document will be provided upon contract award)

1.5 PERFORMANCE REQUIREMENTS SUMMARY.

This contract includes a Performance Requirements Summary (PRS) at PWS 10.0. The PRS plays an integral role in the administration of the contract. In addition to any applicable inspection clauses or other related terms and conditions contained in the contract, the PRS shall serve as a primary tool for inspection and acceptance of services as facilitated by the Contracting Officer’s Representative (COR). Evaluation of the Contractor’s overall performance shall be in accordance with the performance standards set forth in the PRS, and will be conducted by the COR. The PRS constitutes a material aspect of the contract and will not be changed or otherwise modified without prior written approval of the Contracting Officer.

2.0 SPECIFIC REQUIREMENTS/TASKS

The resultant IDIQ contract will be used to conduct crowdsourced vulnerability discovery and disclosure activities across the full range of networks, systems, and information, including web applications, software, source code, software- embedded devices and other technologies as solicited across the whole Department of Homeland Security, or other assets as deemed appropriate by the program office. Work performed under the resultant IDIQ contract will be categorized as detailed below:

Private Assets: These may include but are not limited to closed networks, software-embedded https://www.congress.gov/115/plaws/publ390/PLAW-115publ390.pdf devices, proprietary source code, or other private or internal systems not generally accessible via the public Internet.

● Given the sensitive nature of the potential assets, participation would be invite-only and feature more limited participation than activities associated with public assets.

● Researchers conducting auditable crowdsourced vulnerability discovery and disclosure activities through a secure portal on the contractor’s platform against a variety of sensitive but Internet-connected assets, as well as non-Internet connected assets. The government defines auditable as the ability of a vendor to attribute a given action (vulnerability submission or exploitation attempt) to a researcher given logged information collected from the affected government system

● Contractors will provide a mechanism for logging findings during a private asset event. This could either be accomplished by putting an instantiation of their platform on the private network or logging findings in a common (CSV, XML, or JSON) format.

● Testing content hosted by DHS through a secure contractor portal where Internet Protocol (IP) addresses are logged and/or directly provisioned by the contractor and other data are captured to allow for auditable record capture

● The platform must have a secure portal capable of continuous monitoring and auditing of researcher activities.

● Scoped Time-boxed and/or continuous crowdsourced efforts ranging from 25 to 200 (or less or more) total researchers depending on the needs of the government.

Continuous bounty is defined as a bounty that runs for a 12 month period.

● All activities under each task order will include commercial background check and may include geolocation and/or citizenship verification requirements from the government as a condition of researcher participation. These checks shall be the contractor responsibility. The contractor must be willing to provide proof of completion of these checks for each researcher if requested by the government.

Additional researcher vetting requirements may be made at the Task Order level at the determination of the government.

Public Assets: These may include but are not limited to Internet-accessible assets, including public-facing websites, networks, systems, cloud environments, and applications that are Internet connected.

● Enabling researchers to conduct remote, Internet-based, crowdsourced vulnerability discovery and disclosure services against public assets.

● Small scope time-boxed crowdsourced efforts with less than 300 total researchers or larger scaled crowdsourced efforts with up to 1,500 total researchers.

● Global, open-ended crowdsourced efforts open to anyone willing to participate.

● A robust public affairs and community outreach capability to conduct public outreach and sensitive coordination with researchers. Sensitive coordination is defined as acting as the intermediary between the researcher and DHS in the event a researcher requests permission to publish a vulnerability finding. This will cover the coordination with the researcher that will occur in the event DHS approves or rejects the request to publish.

Overlapping Activities:

● Generation of high-quality vulnerability reports that enable DHS to efficiently remediate asset vulnerabilities;

● Provide comprehensive vulnerability triaging, validation, and prioritization within 48 hours of submission, and reporting to the DHS System Owner to ensure it can patch the vulnerability as soon as feasible;

● Ability to create customized vulnerability workflow management and track vulnerabilities throughout the remediation lifecycle;

● Assist the DHS System Owner in identifying and developing mitigation approaches for discovered vulnerabilities;

● Ability to provide a means to easily export vulnerability reports to other systems (JIRA, etc.) and synchronize vulnerability remediation statuses between multiple systems through common format (CSV, XML, or JSON) or direct system integration;

● Conduct all management and coordination with the researcher community, and coordination with DHS Remediation Team; and

● The contractor shall validate or reject all findings submitted by researchers;

however, DHS requires the ability to view all findings submitted by researchers regardless of the contractor’s determination of validity. At a minimum, validated reports of these findings shall include the time the finding was filed, the time and IP address that was used to validate the findings, the system where the vulnerability was found, and a step-by-step process for replicating the vulnerability.

Existing Security Researcher Community

To meet this requirement, the government requires the contractor to have a pre-existing, security researcher community of over 1000 domestic and international individual researchers with the knowledge, skills, and abilities most applicable and valuable for the goals of the requirement.

The government requires at least 150 active researchers inside of this community. Active researchers are defined as having submitted at least three (3) vulnerability reports through the contractor's platform in the last 12 months prior to the issuance of the Task Order.

Vulnerability Discovery and Disclosure Platform

The contractor must own and maintain a platform to facilitate vulnerability discovery and disclosure activities relative to the resultant IDIQ contract. Platform requirements are stipulated below.

Platforms, conducting work under the IDIQ contract, shall have:

• The capability to securely accept and display vulnerability reports from researchers.

• The capability to actively manage researchers on the assessment, for example, the ability to immediately remove or disable a researcher’s access to all DHS bounty events and information.

• The capability to display relevant metrics on the ongoing state of the assessment, including but not limited to: the total number of vulnerability reports, broken down by criticality, process stage, etc.

• The capability to apply tools and processes, automated as well as manual, to triage reports for the Government. This includes de-duplication of reports.

• The capability to ensure that vulnerability reports, transmitted to Government remediators, are clear and of high quality. This will ensure that Government personnel can immediately remediate identified vulnerabilities.

• The capability to facilitate effective communication between the triage team and researchers and between the triage team and Government remediators. This may include corresponding, separately, with multiple teams.

• The capability to facilitate the secure transmission and storage, of vulnerability information, and adhere to International Organization for Standardization (ISO) standards.

• The capability to implement continuous monitoring as well as auditing tools, to monitor and assess, researcher behavior.

• The capability to capture and inspect encrypted researcher traffic, such as through a Transport Layer Security (TLS) interception proxy.

• The capability to function as a secure portal that is capable of continuous monitoring and auditing of researcher activities, such as those logs collected through simple proxy logging, up to full Packet Capture (PCAP) as identified at the task order level.

At a minimum, DHS requires the contractor to possess the ability to continuously monitor individual researcher activity for the duration of the live-assessment, and the ability to audit researcher activity post-assessment. At a minimum, DHS requires the contractor to possess the ability to know which individual researchers are accessing (or accessed) specific parts of an assessment at specific points in time. DHS requires the contractor to furnish this information upon request if out-of-scope and/or malicious activity is suspected. Further monitoring/auditing requirements may be indicated at the task order level.

The Government expects six (6) time boxed challenges and two (2) continuous challenges during the first year of the contract, and up to twelve time boxed challenges and five continuous challenges if the option year is exercised. It should be noted that the government expects the contractor to be flexible as the number of challenges may be higher or lower depending on the Department’s needs. There may be task orders with overlapping periods of performance and challenge phases. The period of performance is expected to vary per task order with an average duration of three to twelve months.

The contractor shall have the capacity to conduct inside of the continental United States live events lasting between 1 and 4 days with 15-50 researchers. This shall require the contractor to invite researchers, arrange for researcher travel and lodging, and handle all logistics typically involved with conducting live events. This shall require the contractor to use their platform, possibly in stand-alone format, and provide triage services.

The contractor shall also be responsible for designing competitions and 'gamification' aspects of the event in collaboration with DHS representatives. The contractor will be responsible for executing the agreed to gamification approaches and competitions. The contractor shall also procure and provide physical/tangible awards for these events.

Upon the award of the first task order, the awardee shall have a three week “Transition-In Phase” where the contractor ensures key personnel are in place, builds the initial triage team, and sets up billing and invoice accounts.

Each task order will be divided between three distinct phases. The phases, Pre-assessment, Assessment, and Post-Assessment, will vary in length and is dependent on the scope of the challenge. Further details, specific to each phase, as well as sustained expectations are listed in this section of the PWS.

Below, organized by phase, are the contractor requirements relative to services. Although the contractor may move an activity to different phases with the agreement of the government, the overall process shall include all of the phases.

2.1 TASK ONE. Pre-Assessment

2.1.1 Strategically recruit the best-suited researchers based on their proven experience, and their known skillset, given the challenge (source code, operational functionality).

2.1.2 Conduct criminal background checks on all researchers and geolocation verification checks, if requested, on all researchers before granting them access to any DHS information. The contractor shall not include researchers geolocated through the vendor’s geolocation and citizenship verification process to countries designated by DHS at the Task Order level in any aspect of the bounty program. The contractor must be willing to provide proof of completion of these checks for each researcher if requested by the government.

2.1.3 Work with the DHS Bounty Team, System Owner, and other Tech Stakeholders, to develop the asset scope of the challenge and complete a pre-assessment of the intended assets to determine suitability for participation in a bug bounty event.

2.1.4 Work with the DHS Bounty Team, System Owner, and other Tech Stakeholders, to develop the specific technical parameters for the challenge, including the Rules of Engagement

(ROE).

2.1.5 Suggest payment amounts for researchers based on contractor’s prior experience, and industry best practices for approval by government personnel. Socialize payment amounts to the researchers.

2.1.6 Assist drafting and once finalized, distribute scope of the challenge and the technical parameters (i.e., rules of engagement and restrictions, including legal parameters, non-disclosure agreements, if required) to the researchers.

2.1.7 Configure their existing platform to meet the needs of each assessment as outlined above.

2.2 TASK TWO. Assessment

2.2.1 Communicate vulnerability discovery and disclosure rules of engagement and legal parameters to researchers.

2.2.2 Communicate vulnerability reporting standards and requirements to researchers. The contractor shall validate all findings before providing them to DHS, however DHS requires the ability to view findings which were not validated/rejected by the contractor. At a minimum, the reports of these findings shall include the time the finding was filed, the time and IP address that was used to validate the findings, the system where the vulnerability was found, and a step-by-step process for replicating the vulnerability.

2.2.3 Conduct full packet capture of all researcher activities when required by the government.

2.2.4 Integrate appropriate controls over researcher traffic, include a secure portal for full packet capture capabilities to enable auditability and continuous monitoring of researcher activities.

2.2.5 Flag improper, suspicious, or out-of-scope testing conducted by researchers for DHS.

2.2.6 Use and provide access to an existing platform to receive and aggregate vulnerabilities identified by researchers, and ensure vulnerability reports are of high-qualify enabling efficient remediation efforts. Platform must support tagging or other labeling system to be used for mapping identified vulnerabilities to the system a vulnerability was discovered in.

2.2.7 Make available to the researchers automated testing tools or their outputs to enhance the researchers’ ability to locate vulnerabilities in the in-scope assets.

2.2.8 Ensure subcontractors and security researchers adhere to rules and restrictions as consented to prior to registration and throughout the whole challenge.

2.2.9 Triage incoming vulnerability reports through both automated and manual techniques based on severity to identify submissions most impactful to the DHS asset owner and communicate and assign those vulnerabilities to the DHS Bug Bounty Team based upon mutually agreed upon escalation policies.

2.2.10 Identify duplicate vulnerability reports, and filter out other reports that are ineligible or out of scope, preferably utilizing existing automation tools.

2.2.11 Ensure submitted vulnerability reports are complete, and contain a severity assessment, description, detailed reproductive steps, and recommended remediation fix so DHS can remediate the vulnerability when it is reported.

2.2.12 Engage with personnel responsible for operating, securing and defending the DHS asset on discovered vulnerabilities and facilitate communications between DHS personnel and subcontractors, independent persons or entities, and researchers.

2.2.13 Ensure all identified vulnerabilities are communicated securely to DHS, adhering to common international standards for the secure transmission of sensitive security data.

2.2.14 Have the technical capability (i.e., an Application Program Interface (API)) to export vulnerability reports into many systems (i.e., JIRA), or other dedicated vulnerability management or ticketing system. At a minimum, the vulnerability report must contain the name/IP/identified of the system where the vulnerability was found, the time it was discovered, name of the discovery, and any industry standard identifiers (CVE, etc.) or values (CVSS score, etc.) associated with the vulnerability.

2.2.15 Assist the designated DHS Bug Bounty Team with validating vulnerability reports.

2.2.16 Coordinate the disclosure of vulnerabilities with a multi-vendor/multi-party impact, as necessary. Third-party suppliers of software or hardware technology that may be affected by disclosing certain vulnerabilities may be common and require unique expertise.

2.3 TASK THREE. Post-Assessment

2.3.1 Coordinate with researchers and the designated DHS Bug Bounty Team to ensure open vulnerability reports are adjudicated and closed out to the level of satisfaction of DHS personnel.

2.3.2 As appropriate, provide packet capture and other logs to DHS.

2.3.3 Write a final report which shall include:

• An executive summary of findings;

• Impact of the findings to the DHS mission for the in-scope system(s);

• Conclusions based on the contractor’s experience with DHS bounties as well as its own public and private sector bounties to provide recommendations for remediation, technical strategies to better secure the system, and best practices from industry; and

• Lessons learned from the bounty.

2.3.4 Manage and facilitate the secure, legal payment of monetary and non-monetary awards to researchers for validated and qualifying vulnerability reports. The contractor will ensure that no payments or awards are made to individual researchers or contractors on the U.S. Treasury "Specially Designated Nationals And Blocked Persons List (SDN)" (ref https://home.treasury.gov/policy-issues/financial-sanctions/specially-designated-nationals-and-blocked-persons-list-sdn-human-readable-lists)

2.3.5 The contractor will effectively communicate and coordinate with prospective as well as current researchers to ensure smooth user experience.

2.3.6 The contractor shall design, with the permission of DHS, produce and distribute awards to researchers who have filed at least one (1) valid report during the bounty event. The award may be designed and permission for approval may be sought any time after the award of the Task Order.

2.4 TASK FOUR. Sustainment

2.4.1 During the entire period of performance of the task order, the contractor will effectively communicate and coordinate with prospective researchers to ensure smooth user experience.

2.4.2 Communicate electronically with researchers at each stage of the vulnerability life cycle, including initial receipt, remediation, and acknowledgement/reward.

2.4.3 Securely manage the storage and distribution of credentials to researchers to enable remote vulnerability discovery and disclosure activities against assets that require trusted relationships/connections.

2.4.4 Ensure that the vulnerability discovery and disclosure process can adhere to common international standards for handling vulnerability data, such as ISO 29147 and ISO 30111.

2.4.5 Deliver status reports at the end of the Pre-Assessment, Assessment, and Post-Assessment phases. Deliver final report at the end of the task order and if requested, in a digitally importable format.

2.4.6 Notify DHS within 12 hours if a researcher violates the rules of engagement restrictions and suspend researcher’s access to DHS bounty programs pending DHS response. Contractor will be required to submit additional information requested about such action.

2.4.7 Notify DHS no later than 2 hours after a discovery of a situation (confirmed or not) which could expose or have disclosed DHS vulnerability information to unauthorized parties.

2.4.8 Contractor shall provide notification to DHS regarding any validated critical finding within 1 hour of validation.

2.4.9 Contractor staff and researchers shall use Multi Factor Authentication (MFA) when accessing contractor systems containing vulnerability findings resulting from bug bounty events involving DHS systems.

2.4.10 Contractor shall ensure the platform used to accept, store, and process vulnerability findings from researchers is based in the United States. The contractor shall assume responsibility for protecting the confidentiality of Government records, which is not considered public information. Each contractor or employee of the contractor to whom information may be provided or disclosed shall be notified in writing by the contractor that such information may be disclosed only for purposes and to the extent authorized.

3.0 CONTRACTOR PERSONNEL

3.1 Qualified Personnel

The Contractor shall provide qualified personnel to perform all requirements specified in this

PWS.

3.2 Key Personnel

Key personnel will consist of a Contractor Program Manager. Key personnel will work with designated system owner groups and the program office to ensure mutual understanding of each other’s requirements and objectives, vulnerability validators who confirm the validity of researcher findings before providing them to the system owners, and remediation specialists who will assist system owners in the remediation process.

Before replacing any individual designated as Key Personnel by the Government, the Contractor shall notify the Contracting Officer no less than 15 business days in advance, submit written justification for replacement, and provide the name and qualifications of any proposed substitute(s). All proposed substitutes shall possess qualifications equal to or superior to those of the Key Personnel being replaced, unless otherwise approved by the Contracting Officer. The Contractor shall not replace Key Personnel without approval from the Contracting Officer. The following Contractor personnel are designated as Key Personnel for this requirement. Note: The Government may designate additional Contractor personnel as Key Personnel at the time of award. Additionally, to be clear, researchers are essential to this program but do not adhere to key personnel requirements stated.

The Key Personnel under this contract:

• Program Manager (at the IDIQ Level)

• All other Key Personnel will be defined at the task order level.

3.2.1 Program Manager (PM)

The Contractor PM shall be responsible for all Contractor work performed under this PWS. The Contractor PM shall be a single point of contact for the Contracting Officer and the COR. The name of the Contractor PM, and the name(s) of any alternate(s) who shall act for the Contractor in the absence of the Contractor PM, shall be provided to the Government as part of the Contractor's proposal. The Contractor PM is further designated as Key by the Government.

During any absence of the Contractor PM, only one alternate shall have full authority to act for the Contractor on all matters relating to work performed under this contract. The Contractor PM and all designated alternates shall be able to read, write, speak and understand English.

Additionally, the Contractor shall not replace the Contractor PM without prior approval from the Contracting Officer.

The Contractor PM shall have at minimum three (3) years of experience with similar projects, knowledgeable with metrics, accounting, and knowledge management.

The Contractor PM shall be available to the COR via telephone between the hours of 0900 and 1700 ET, Monday through Friday, and shall respond to a request for discussion or resolution of technical problems within 24 hours of notification. In addition to availability outside core hours to respond to emergency situations as determined by COR.

3.3 Employee Identification

3.3.1 Contractor employees visiting Government facilities shall wear an identification badge that, at a minimum, displays the Contractor name, the employee’s photo, name, clearance-level and badge expiration date. Visiting Contractor employees shall comply with all Government escort rules and requirements. All Contractor employees shall identify themselves as

Contractors when their status is not readily apparent and display all identification and visitor badges in plain view above the waist at all times.

3.3.2 Contractor employees working on-site at Government facilities shall wear a Government issued identification badge. All Contractor employees shall identify themselves as Contractors when their status is not readily apparent (in meetings, when answering Government telephones, in e-mail messages, etc.) and display the Government issued badge in plain view above the waist at all times.

3.4 Employee Conduct

Contractor’s employees shall comply with all applicable Government regulations, policies and procedures (e.g., fire, safety, sanitation, environmental protection, security, “off limits” areas, wearing of parts of DHS uniforms, and possession of weapons) when visiting or working at Government facilities. The Contractor shall ensure Contractor employees present a professional appearance at all times and that their conduct shall not reflect discredit on the United States or the Department of Homeland Security. The Contractor Program Manager shall ensure Contractor employees understand and abide by Department of Homeland Security established rules, regulations and policies concerning safety and security.

3.5 Removing Employees for Misconduct or Security Reasons

The Government may, at its sole discretion (via the Contracting Officer), direct the Contractor to remove any Contractor employee from DHS facilities for misconduct or security reasons.

Removal does not relieve the Contractor of the responsibility to continue providing the services required under the contract. The Contracting Officer will provide the Contractor with a written explanation to support any request to remove an employee.

4.0 OTHER APPLICABLE CONDITIONS

4.1 SECURITY

Contractor access to unclassified, but Security Sensitive Information may be required under this PWS. Contractor employees shall safeguard this information against unauthorized disclosure or dissemination.

4.2 PERIOD OF PERFORMANCE

The period of performance for this contract is a one-year base period with four one-year option periods.

IDIQ Period Ordering Period Anticipated Dates (Subject to

Change) Base Period 12 months 8/19/2022-8/18/2023 Option Period 1 12 months 8/19/2023-8/18/2024 Option Period 2 12 months 8/19/2024-8/18/2025

Option Period 3 12 months 8/19/2025-8/18/2026 Option Period 4 12 months 8/19/2026-8/18/2027

4.3 PLACE OF PERFORMANCE

The primary place of performance will be the Contractor’s facilities with infrequent visits to the Department of Homeland Security facilities in the Washington Metro Area.

4.4 HOURS OF OPERATION

In Pre-Assessment and Post-Assessment phases of a Bug Bounty event, the normal business work hours for the Contractor shall be between 8am and 7pm ET on weekdays, except Federal holidays.

In the Assessment phase of a Bug Bounty event, the normal business hours for the Contractor shall be defined in the Task Orders (e.g. if the event is 24x7 the Contractor shall ensure staffing to triage and/or escalate findings appropriately, or if a live-event the Contractor shall ensure staffing to triage and/or escalate findings during the hours the event is conducted).

However, there may be occasions when Contractor employees shall be required to work other than normal business hours, including weekends and holidays, to fulfill requirements under this

PWS.

The list of Federal Holidays covered under this contract can be found at:

https://www.opm.gov/policy-data-oversight/pay-leave/federal-holidays/

4.5 TRAVEL/OTHER DIRECT COSTS

The Contractor may be required to travel in support of this requirement. Travel will include locations within Continental U.S. Travel costs shall be included in the Administrative Services CLIN(s).

4.6 POST AWARD CONFERENCE

The Contractor shall attend a Post Award Conference with the Contracting Officer and the COR no later than 10 business days after the date of award. The purpose of the Post Award Conference, which will be chaired by the Contracting Officer, is to discuss technical and contracting objectives of this contract and review the Contractor's draft project plan. The Post Award Conference will be held at the Government’s facility, located at 300 7th St SW, Washington, DC 20024 or via video/teleconference.

4.7 PROJECT PLAN

The Contractor shall provide a draft Project Plan at the Post Award Conference for Government review and comment. The Contractor shall provide a final Project Plan to the COR not later than 15 business days after the Post Award Conference.

4.8 BUSINESS CONTINUITY PLAN

The Contractor shall prepare and submit a Business Continuity Plan (BCP) to the Government.

The BCP Plan shall be due 30 business days after the date of award, and will be updated on an annual basis. The BCP shall document Contractor plans and procedures to maintain support during an emergency, including natural disasters and acts of terrorism. The BCP, at a minimum, shall include the following:

• A description of the Contractor’s emergency management procedures and policy;

• A description of how the Contractor will account for their employees during an emergency;

• How the Contractor will communicate with the Government during emergencies; and

• A list of primary and alternate Contractor points of contact, each with primary and alternate:

• Telephone numbers

• E-mail addresses

4.8.1 Individual BCPs shall be activated immediately after determining that an emergency has occurred, shall be operational within 12 hours of activation or as directed by the Government, and shall be sustainable until the emergency situation is resolved and normal conditions are restored or the contract is terminated, whichever comes first. In case of a life threatening emergency, the COR shall immediately make contact with the Contractor Program Manager to ascertain the status of any Contractor personnel who were located in Government controlled space affected by the emergency. When any disruption of normal, daily operations occur, the Contractor Program Manager and the COR shall promptly open an effective means of communication and verify:

• Key points of contact (Government and contractor)

• Temporary work locations (alternate office spaces, telework, virtual offices, etc.)

• Means of communication available under the circumstances (e.g. email, webmail, telephone, FAX, courier, etc.)

• Essential Contractor work products expected to be continued, by priority

4.8.2 The Government and Contractor Program Manager shall make use of the resources and tools available to continue contracted functions to the maximum extent possible under emergency circumstances.

4.9 PROGRESS REPORTS

The Contractor Program Manager shall provide a monthly progress report Contracting Officer and COR via electronic mail. This report shall include a summary of all Contractor work performed, all direct costs by line item, an assessment of technical progress, schedule status, any travel conducted and any Contractor concerns or recommendations for the previous reporting period.

4.10 PROGRESS MEETINGS

The Contractor Program Manager shall be available to meet with the COR upon request to present deliverables, discuss progress, exchange information and resolve emergent technical problems and issues. These meetings shall take place via video/teleconference.

4.11 GENERAL REPORT REQUIREMENTS

The Contractor shall provide all written reports in electronic format with read/write capability using applications that are compatible with DHS workstations (Windows XP and Microsoft Office Applications).

4.12 INTELLECTUAL PROPERTY

The contractor may be granted limited authority to use the official seal of the Department of Homeland Security (DHS), or the official seals of all DHS Components for limited purposes in an order. If granted, use of all logos must be discontinued at the conclusion of each order or unless provided advanced written approval by the Contracting Officer. Without written approval, no contractor, or subcontractor, is authorized to use the official seal of DHS for any other purpose. All data and reports generated as a result of Task Orders conducted under this IDIQ contract are the property of the US Government and may not be shared, used, or distributed without the expressed written consent of the US Government.

4.13 PROTECTION OF INFORMATION

Contractor access to information protected under the Privacy Act is required under this PWS.

Contractor employees shall safeguard this information against unauthorized disclosure or dissemination in accordance with the law and Government policy and regulation.

Contractor access to proprietary information is required under this PWS. Contractor employees shall safeguard this information against unauthorized disclosure or dissemination in accordance with the law and Government policy and regulation.

Contractor access to proprietary information is required under this PWS. Contractor employees shall safeguard this information against unauthorized disclosure or dissemination in accordance with DHS MD 11042.1, Safeguarding Sensitive But Unclassified (For Official Use Only) Information. The Contractor shall ensure that all Contractor personnel having access to business or procurement sensitive information sign a non-disclosure agreement (DHS Form 11000-6).

4.14 SECTION 508 COMPLIANCE

Section 508 of the Rehabilitation Act, as amended by the Workforce Investment Act of 1998 (P.L. 105-220) (codified at 29 U.S.C. § 794d) requires that when Federal agencies develop, procure, maintain, or use information and communications technology (ICT), it shall be accessible to people with disabilities. Federal employees and members of the public with disabilities must be afforded access to and use of information and data comparable to that of Federal employees and members of the public without disabilities.

All products, platforms and services delivered as part of this work statement that, by definition, are deemed ICT shall conform to the revised regulatory implementation of Section 508 Standards, which are located at 36 C.F.R. § 1194.1 & Appendix A, C & D, and available at https://www.gpo.gov/fdsys/pkg/CFR-2017-title36-vol3/pdf/CFR-2017-title36-vol3-part1194.pdf.

In the revised regulation, ICT replaced the term electronic and information technology (EIT) used in the original 508 standards. ICT includes IT and other equipment.

Exceptions for this work statement have been determined by DHS and only the exceptions described herein may be applied. Any request for additional exceptions shall be sent to the Contracting Officer and a determination will be made according to DHS Directive 139-05, Office of Accessible Systems and Technology, dated November 12, 2018 and DHS Instruction 139-05- 001, Managing the Accessible Systems and Technology Program, dated November 20, 2018, or any successor publication.

4.14.1 Section 508 Requirements for Technology Services

When providing installation, configuration or integration services for ICT, the Contractor shall not reduce the original ICT item's level of Section 508 conformance prior to the services being performed.

When providing maintenance upgrades, substitutions, and replacements to ICT, the contractor shall not reduce the original ICT’s level of Section 508 conformance prior to upgrade, substitution or replacement. The agency reserves the right to request an Accessibility Conformance Report (ACR) for proposed upgrades, substitutions and replacements prior to acceptance. The ACR should be created using the on the Voluntary Product Accessibility Template Version 2.2 508 (or successor versions). The template can be located at https://www.itic.org/policy/accessibility/vpat

When providing Platform as a Service (PaaS) or Software as a Service (SaaS), the contractor shall ensure services conform to the applicable Section 508 standards (including the requirements in Chapter 5 for software and WCAG Level A and AA Level 2.0 success criteria for web and software. When the requirements in Chapter 5 do not address one or more software functions, the Contractor shall ensure conformance to the Functional Performance Criteria specified in Chapter 3.) The agency reserves the right to request an Accessibility Conformance Report (ACR) for PaaS and SaaS offerings. The ACR should be created using the Voluntary Product Accessibility Template Version 2.2 508 (or later). The template can be located at https://www.itic.org/policy/accessibility/vpat

When providing cloud hosting services (Infrastructure as a Service, Platform as a Service, Software as a Service, etc.) the Contractor shall ensure user administrative screens, dashboards and portals used to configure, and monitor cloud services conform to the Section 508 standards.

The Contractor shall ensure cloud hosting services shall not reduce the level of Section 508 conformance for ICT migrated by DHS to the cloud hosting environment.

When developing or modifying ICT, the Contractor is required to validate ICT deliverables for conformance to the applicable Section 508 requirements. Validation shall occur on a frequency that ensures Section 508 requirements is evaluated within each iteration and release that contains.

When modifying, installing, configuring or integrating commercially available or government-owned ICT, the Contractor shall not reduce the original ICT Item’s level of Section 508 conformance.

When developing or modifying web based and electronic content components, except for electronic documents and non-fillable forms provided in a Microsoft Office or Adobe PDF format, the Contractor shall demonstrate conformance to the applicable Section 508 standards (including WCAG 2.0 Level A and AA Success Criteria) by conducting testing using the DHS Trusted Tester for Web Methodology Version 5.0 or successor versions, and shall ensure testing is conducted by individuals who are certified by DHS on version 5.0 or successor versions (e.g.

“DHS Certified Trusted Testers”). The Contractor shall provide the Trusted Tester Certification IDs to DHS upon request. Information on the DHS Trusted Tester for Web Methodology Version 5.0, related test tools, test reporting, training, and tester certification requirements is published at https://www.dhs.gov/trusted-tester.

When developing or modifying electronic documents and forms provided in a Microsoft Office or Adobe PDF format, the Contractor shall demonstrate conformance to the applicable to the applicable Section 508 standards (including WCAG Level A and AA Level 2.0 Success Criteria) by conducting testing using the test methods published under “Accessibility Tests for Documents” at https://www.dhs.gov/compliance-test-processes.

When developing or modifying ICT deliverables that contain the ability to automatically generate electronic documents and forms in Microsoft Office and Adobe formats, or when the capability is provided to enable end users to design and author web based electronic content (i.e.

surveys, dashboards, charts, data visualizations, etc.), the Contractor shall demonstrate the ability to ensure these outputs conform to the applicable Section 508 standards (including WCAG 2.0 Level A and AA Success Criteria). The Contractor shall demonstrate conformance by conducting testing and reporting test results based on representative sample outputs. For outputs produced as Microsoft Office and Adobe PDF file formats, the Contractor shall use the test methods published under “Accessibility Tests for Documents”, which are published at https://www.dhs.gov/compliance-test-processes. For outputs produced as web based electronic content, the Contractor shall use the DHS Trusted Tester for Web Methodology Version 5.0, or successor versions. This methodology is published at https://www.dhs.gov/trusted-tester.

When developing or modifying software functions of ICT, the Contractor shall demonstrate conformance to the applicable Section 508 standards (including the requirements in Chapter 5 and WCAG 2.0 Level A and AA Success Criteria). When the requirements in Chapter 5 do not address one or more software functions, the Contractor shall demonstrate conformance to the Functional Performance Criteria specified in Chapter 3. The Contractor shall use a test process capable of validating conformance to all applicable Section 508 standards for software functionality delivered pursuant to this contract. The Contractor may utilize the DHS Trusted Tester Methodology for Web and Software Version 4.0 as a component of the overall test process used. This version of the test process provides partial test coverage of the Section 508 standards that apply to software. If the Contractor uses this test process, the Contractor shall address the test coverage gaps through additional test procedures. Information on the DHS Trusted Tester Methodology for Web and Software Version 4.0, including coverage against the applicable Section 508 standards for software as well as gaps that need to be addressed through other test methods, related test tools, and training is published at https://www.dhs.gov/trusted-tester.

Contractor personnel shall possess the knowledge, skills and abilities necessary to address the accessibility requirements in this work statement.

4.14.2 Section 508 Deliverables

Section 508 Test Plans: When developing or modifying ICT pursuant to this contract, the Contractor shall provide a detailed Section 508 Conformance Test Plan. The Test Plan shall describe the scope of components that will be tested, an explanation of the test process that will be used, when testing will be conducted during the project development life cycle, who will conduct the testing, how test results will be reported, and any key assumptions.

Section 508 Test Results: When developing or modifying ICT pursuant to this contract, the Contractor shall provide test results in accordance with the Section 508 Requirements for Technology Services provided in this solicitation.

Section 508 Accessibility Conformance Reports: For each ICT item offered through this contract (including commercially available products, and solutions consisting of ICT that are developed or modified pursuant to this contract), the Offeror shall provide an Accessibility Conformance Report (ACR) to document conformance claims against the applicable Section 508 standards. The ACR shall be based on the Voluntary Product Accessibility Template Version

2.0 508 (or successor versions). The template can be found at https://www.itic.org/policy/accessibility/vpat. Each ACR shall be completed by following all of the instructions provided in the template, including an explanation of the validation method used as a basis for the conformance claims in the report.

Other Section 508 Documentation: The following documentation shall be provided upon request for ICT items offered through this contract:

• Documentation of features provided to help achieve accessibility and usability for people with disabilities.

• Documentation on how to configure and install the ICT Item to support accessibility.

• Documentation of core functions that cannot be accessed by persons with disabilities.

• Documentation of remediation plans to address non-conformance to the Section 508.

5.0 GOVERNMENT TERMS & DEFINITIONS

5.1 COR – Contracting Officer’s Representative

5.2 DHS - Department of Homeland Security

5.3 PM – Program Manager

5.4 CVE – Common Vulnerabilities and Exposures

5.5 CVSS – Common Vulnerability Scoring System

5.6 API – Application Program Interface

5.7 BCP – Business Continuity Plan

6.0 GOVERNMENT FURNISHED RESOURCES

The Government will provide technical information, material and forms unique to the Government for supporting the task. Government unique information, including software, system configuration files, IP ranges, and other Government unique information related to this requirement, which is necessary for contractor performance, will be made available to the contractor. The COR will be the Point of Contact for identification of any required information to be supplied by the Government. Government Furnished Materials also includes any information received during the challenge from Government employees.

7.0 CONTRACTOR FURNISHED PROPERTY

The Contractor shall furnish all facilities, materials, equipment and services necessary to fulfill the requirements of this contract, except for the Government Furnished Resources specified in PWS 2.0 and PWS 6.0.

8.0 GOVERNMENT ACCEPTANCE PERIOD

The COR will review deliverables prior to acceptance and provide the contractor with an e-mail that provides documented reasons for non-acceptance. If the deliverable is acceptable, the COR will send an e-mail to the Contractor notifying it that the deliverable has been accepted.

8.1 The COR will have the right to reject or require correction of any deficiencies found in the deliverables that are contrary to the information contained in the Contractor’s accepted proposal.

In the event of a rejected deliverable, the Contractor will be notified in writing by the COR of the specific reasons for rejection. The Contractor may have an opportunity to correct the rejected deliverable and return it per delivery instructions.

8.2 The COR will have 10 business days to review deliverables and make comments. The Contractor shall have 10 business days to make corrections and redeliver.

8.3 All other review times and schedules for deliverables shall be agreed upon by the parties based on the final approved Project Plan. The Contractor shall be responsible for timely delivery to Government personnel in the agreed upon review chain, at each stage of the review. The Contractor shall work with personnel reviewing the deliverables to assure that the established schedule is maintained.

9.0 DELIVERABLES

ITEM PWS

REFERENCE

DELIVERABLE /

EVENT DUE Date

DISTRIBUTION

1 4.6 Post Award Conference No later than 10 business days after the date of award

N/A

2 4.6, 4.7 Draft Contractor Project Plan

At the Post Award Conference

COR, Contracting Officer

3 4.7 Final Contractor Project Plan

15 business days after the Post Award Conference

COR, Contracting Officer

4 4.8 Original Business Continuity Plan

30 business days after the date of award

CO…