HSTS05-16-Q-ACQ002_SOW_Reverse_Auction_ACQ002.pdf

Solicitation HSTS05-16-Q-ACQ002

STATEMENT OF WORK

TSA Office of Acquisition Web-Based Reverse Auctioning Tool

1. Background

The Transportation Security Administration (TSA) Office of Acquisition (OA) is responsible for the execution and administration of all contract vehicles awarded by the agency. The nature of work entails the planning, negotiation, award, and administration of contracts of various types and sizes to support program offices within the organization. The OA seeks to streamline the acquisition process by taking advantage of innovative e-procurement technologies that will assist TSA in leveraging limited resources, reducing administrative tasks and associated labor costs while ensuring regulatory compliance, maintaining high levels of competition, obtaining fair and reasonable prices, and meeting the agency’s socioeconomic small business goals. The TSA OA is a largely centralized office located in the Pentagon

City area of Arlington, Virginia but with satellite offices in Seattle, Washington and Atlantic City, New

Jersey.

2. Scope of Work

The Transportation Security Administration (TSA) requires an existing web-based solution that assists the procurement office and customers in soliciting, evaluating, and awarding multiple contract types for supplies and select services from established networks of vendors. The reverse auction tool shall also be capable of registering eligible vendors within the tool to be able to receive auctions and submit quotes to the Government. Vendors shall also be able to submit questions directly to the buyer regarding the RFQ;

the contracting staff shall also be able to respond to one or all quoters with answers to questions and comments to statements. TSA requires a solution that is vendor paid (awarded vendor pays fee to the company), and not a licensing agreement model.

TSA buyers shall have the ability to set a target price, specify that the winning price must be equal to or better than this target price, optionally set the criteria for selecting the winner(s), include TSA terms and conditions, and set a specified start and end date of each reverse auction. Bidders or suppliers shall be able to submit successively lower bids than the target price or leading bid to anonymously quote against each other for a TSA requirement until the reverse auction closes. Bidders shall not have knowledge of the other bids posted or bidders participating in auction. At the end of the auction, the buyer shall have the option to select the winner(s) manually.

3. Description of Work

1. The web-enabled reverse auctioning tool shall permit TSA procurement personnel, which includes both federal and contractor employees, to conduct real-time competed auctions for supplies and services. The tool allows employees to post online reverse auctions formatted as

Request for Quotations (RFQs), utilize best value award criteria, Low Price Technically

Acceptable (LPTA) award criteria, and establish auction start and end times. The system shall be versatile to allow buyers to have complete and independent control of the bidding process to post auctions, modify auctions, cancel auctions at any time if it is in the best interest of the

Government, and award to any vendor providing a quote in accordance with the established evaluation criteria. The reverse auction system website must be capable of simultaneous transactions in support of approximately 120 users (buyers) creating and conducting numerous auctions among various vendors for a multitude of items and services.

The Contractor is expected to provide ancillary support to the OA in the performance of reverse auctioning services to include, but not limited to, the following:

Train OA users

Set up and administer accounts for OA users

Provide technical/user support (help desk) to troubleshoot problems with the system

Provide a qualified list of suppliers

Recruit and train new sellers to expand the supplier pool

Allow TSA to provide suggested sources

Notify vendors of any new postings

Allow Suppliers/bidders to bid down prices and submit multiple bids

Hide the identity of bidders so it is unknown to each other

When necessary, the Contractor shall serve proxy to post and cancel bids

Provide expert reverse auctioning advice when necessary (i.e. timeframe of bids, cancellation and reposting of bids, etc.)

Provide necessary online access to the following information about each activity/bid o Summary of all bids submitted per event o Details of each bid submitted per event o Vendor’s specific information (i.e. Company name, address, point of contact (POC), POC phone number & e-mail address, company’s tax ID number, company’s DUNs number, etc.)

Create and maintain solid relationships with the TSA user community.

System Features

Buyer registration and unique password authentication within the Reverse Auction System website (account set-up and maintenance).

Allow buyers to utilize existing DHS Strategic Sourcing Contract vehicles, multiple award contracts (MACS), or government-wide acquisition contracts (GWACS) with the system.

Load TSA MACs into the system upon request and restrict access only to TSA OA buyers and other buyers explicitly authorized by the Contracting Officer’s Representative (COR).

Buyers posting or reposting a solicitation must obtain supervisor approval.

During the creation of a reverse auction event, buyers have the ability to set solicitation(s) aside based on various socio-economic classifications.

Only buyers shall have the authority to 'award', 'cancel', or 'modify' an auction event.

Buyer function that allows the identification of the contracting officer and/or contract specialist point of contact information associated with a reverse auction event.

Ability for DHS to re-assign a buyer.

Ability for DHS Buyer to pre-populate and change/add standard contracting clauses.

Ability for buyers to view/print bid result for contract filing purposes.

4. Deliverables

Monthly and Annual reports shall be submitted electronically to the Contracting Officer, Contract

Specialist, Contracting Officer Representative (COR) and other TSA personnel identified by the COR.

These reports can be in Contractor format, but must include all the required elements described in this section for each respective report. Monthly reports shall be due no later than five (5) business days after the end of the reporting period. Annual reports shall be due no later than fifteen (15) business days after the reporting period. 4. The reverse auction tool shall be capable of delivering reporting data so that TSA can track spend and savings data for procurements completed using the tool. Some reporting that might be required or requested includes, but is not limited to, number of auctions by buyer-component-contract, number of bidders, number of bids and spend-savings calculations.

4.1 Monthly Reports

The Contractor shall submit a monthly report summarizing and detailing all procurement activities for the previous month including but not limited to all posted, awarded, and canceled procurements with the name of the contracting activity, date of the action, bid control number, total dollar amount, name of buyer and departmental buying divisions, name of vendor, business size, contract vehicle utilized, transaction fee charged to vendor based on award price (actual and percentage), and percentage savings based on target price set by the buyer. Buys reported shall be segregated by departmental buying division.

4.2 Annual Reports

At the conclusion of each year of performance, the Contractor shall create a comprehensive report that lists all procurement activities for the year including all elements listed under the Monthly Reports in

Section 4.1.

5. Government Furnished Resources

The Contractor shall provide all resources necessary to operate the reverse auctioning tool and provide the ancillary support described herein.

5. Points of Contact and Mailing Address

To Be Provided Upon Contract Award

6. Place of Performance

The reverse auctioning system shall be hosted and operated at the Contractor’s facilities. The Contractor is expected to perform training and related support work when required on-site at TSA facilities in

Arlington, VA and Atlantic City, NJ but will not be provided with permanent workspaces.

7. Hours of Work

The Contractor is expected to provide online access to its reverse auction services 24 hours a day, 7 days a week, and 365 days per year (24x7x365) within the parameters of its commercially advertised system availability. The Contractor will alert the COR of planned system outages for maintenance, upgrades, etc., with as much advance notice as feasible but not less than three business days before the outage.

Technical and customer service support shall be available Monday through Friday, except Federal holidays, between the hours of 8:00 AM and 5:00 PM (EST). Federal holidays for each year of performance can be found at http://www.opm.gov/fedhol/index.asp.

8. Period of Performance

The period of performance for furnishing reverse auction services is 12 months from date the contract award, with four (4) 12-month option periods, subject to the Government’s needs and the availability of funds.

9. Security and Privacy

Contractor personnel having access to TSA’s sensitive procurement information will be required to sign the attached Nondisclosure Agreement within the timeframe agreed to by the Contracting Officer, prior to the start of the period of performance. All TSA information must be held in confidence and may not be shared with anyone outside of the Transportation Security Administration. See TSA Special

Requirements for further guidance.

Accessibility Requirements (Section 508)

Section 508 of the Rehabilitation Act, as amended by the Workforce Investment Act of 1998 (P.L. 105-220) requires that when Federal agencies develop, procure, maintain, or use electronic and information technology (EIT), they must ensure that it is accessible to people with disabilities. Federal employees and members of the public who have disabilities must have equal access to and use of information and data that is comparable to that enjoyed by non-disabled Federal employees and members of the public.

All EIT deliverables within this work statement shall comply with the applicable technical and functional performance criteria of Section 508 unless exempt. Specifically, the following applicable EIT accessibility standards have been identified:

Section 508 Applicable EIT Accessibility Standards

36 CFR 1194.21 Software Applications and Operating Systems, applies to all EIT software applications and operating systems procured or developed under this work statement including but not limited to GOTS and COTS software. In addition, this standard is to be applied to Web-based applications when needed to fulfill the functional performance criteria. This standard also applies to some Web based applications as described within 36 CFR 1194.22.

http://www.opm.gov/fedhol/index.asp

36 CFR 1194.22 Web-based Intranet and Internet Information and Applications, applies to all Web-based deliverables, including documentation and reports procured or developed under this work statement. When any Web application uses a dynamic (non-static) interface, embeds custom user control(s), embeds video or multimedia, uses proprietary or technical approaches such as, but not limited to, Flash or Asynchronous Javascript and XML (AJAX) then 1194.21 Software standards also apply to fulfill functional performance criteria.

36 CFR 1194.31 Functional Performance Criteria, applies to all EIT deliverables regardless of delivery method. All EIT deliverable shall use technical standards, regardless of technology, to fulfill the functional performance criteria.

36 CFR 1194.41 Information Documentation and Support, applies to all documents, reports, as well as help and support services. To ensure that documents and reports fulfill the required 1194.31 Functional

Performance Criteria, they shall comply with the technical standard associated with Web-based Intranet and Internet Information and Applications at a minimum. In addition, any help or support provided in this work statement that offer telephone support, such as, but not limited to, a help desk shall have the ability to transmit and receive messages using TTY.

Sensitive Information Required Special Contract Terms (MARCH 2015) SAFEGUARDING OF SENSITIVE

INFORMATION (MAR 2015)

(a) Applicability. This clause applies to (TBD), 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. The DHS Sensitive Systems Policy Directive 4300A and the DHS 4300A Sensitive Systems Handbook 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 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.

(1) Complete the Security Authorization process. The SA process shall proceed according to the DHS

Sensitive Systems Policy Directive 4300A (Version 11.0, April 30, 2014), or any successor publication, DHS 4300A Sensitive Systems Handbook (Version 9.1, July 24, 2012), or any successor publication, and the Security Authorization Process Guide including templates.

(i) 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.

(ii) 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.

(iii) 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.

(End of clause)

2. Information Assurance Requirements for TSA Government Acquisitions

A. Controls

A.1. The Contractor shall comply with Department of Homeland Security (DHS) and Transportation

Security Administration (TSA) technical, management and operational security controls to ensure that the Government's security requirements are met. These controls are described in DHS PD 4300A and

TSA MD 1400 series security policy documents and are based on the NIST Special Publication (SP) 800-53 standards.

A.2. The Contractor shall include this prospective clause in all subcontracts at any tier where the subcontractor may have access to “sensitive information” as defined in this prospective clause.

A.3. The Contractor shall be privy to sensitive organizational information. A Privacy Management

Plan and signed DHS Non-Disclosure Agreements (NDAs) for Contractor personnel are required within

(30) calendar days of the contract start date.

A.4. The Homeland Security Presidential Directive 12 (HSPD-12) requires the use of the Personal

Identity Verification (PIV) credentials as the common means of authentication for access to TSA’s facilities, networks, and information systems. Personal Identity Verification (PIV) credentials shall be used as the primary means of logical authentication for TSA sensitive systems.

B. General Security Responsibilities for Contract Performance

B.1. The Contractor shall ensure that its employees follow all policies and procedures governing physical, environmental, and information security described in the various TSA regulations pertaining thereto, good business practices, and the specifications, directives, and manuals for conducting work to generate the products as required by this contract. Personnel will be responsible for the physical security of their area and government furnished equipment (GFE) issued to them under the provisions of the contract.

B.2. All Contractor employees shall receive initial TSA IT Security Awareness Training within 60 days of assignment to the contract.

B.3. Refresher training must be completed annually thereafter.

B.4. Role Based training for contract employees individuals with Significant Security Responsibility

(SSR), whose job proficiency is required for overall network security within TSA, will be in accordance with DHS and TSA policy.

B.5. Individuals with SSR will have a documented individual training and education plan, which will ensure currency with position skills requirements, with the first course to be accomplished within 90 days of employment or change of position. The individual training plan will be refreshed annually or immediately after a change in the individual’s position or related position description requirements.

B.6. The education and training will meet standards established by the National Institute of

Standards and Technology (NIST) and set forth in DHS and TSA security policy.

B.7. Evidence of training provided to personnel will be available upon request of the DHS IT Security

Training Office, or during DHS/TSA onsite validation visits performed on a periodic basis.

C. Configuration Management (hardware/software)

C.1. Hardware or software configuration changes shall be in accordance with the DHS Information

Security Performance Plan (current year and any updates thereafter), the DHS Continuous Diagnostics and Mitigation (CDM) Program to include dashboard reporting requirements and TSA’s Configuration

Management policy. The TSA Chief Information Security Officer (CISO)/ Information Assurance and

Cyber Security Division (IAD) must be informed of and involved in all configuration changes to the TSA IT environment including systems, software, infrastructure architecture, infrastructure assets, and end user assets. The TSA IAD will approve any request for change prior to any development activity occurring for that change and will define the security requirements for the requested change.

C.2. The Contractor shall ensure all application or configuration patches and/or Request for Change

(RFC) have approval by the Technical Discussion Forum (TDF), and Systems Configuration Control Board

(SCCB) and lab regression testing prior to controlled change release under the security policy document, TSA Management Directive (MD) 1400.3 and TSA Information Assurance Handbook, unless immediate risk requires immediate intervention. Approval for immediate intervention (emergency change) requires approval of the TSA CISO, SCCB co-chairs, and the appropriate Operations Manager, at a minimum.

C.3. The Contractor shall ensure all sites impacted by patching are compliant within 14 days of change approval and release.

C.4. The acquisition of commercial-off-the-shelf (COTS) Information Assurance (IA) and IA-enabled IT products (to be used on systems entering, processing, storing, displaying, or transmitting “sensitive information”) shall be limited to those products that have been evaluated and validated, as appropriate, in accordance with the following:

• The NIST FIPS validation program.

• The National Security Agency (NSA)/National Institute of Standards and Technology (NIST)

National Information Assurance Partnership (NIAP) Evaluation and Validation Program.

• The International Common Criteria for Information Security Technology Evaluation Mutual

Recognition Agreement.

C.5. US Government Configuration Board and DHS Configuration Guidance

a) The provider of information technology shall certify applications are fully functional and operate correctly as intended on systems using the US Government Configuration Board (USGCB) and in accordance with DHS and TSA guidance.

1. USGCB Guidelines:

a. http://usgcb.nist.gov/usgcb_content.html

2. DHS Sensitive Systems Configuration Guidance

a. http://dhsconnect.dhs.gov/org/comp/mgmt/cio/iso/Pages/sscg.aspx

b) The standard installation, operation, maintenance, updates and/or patching of software shall not alter the configuration settings from the approved USGCB configuration. The information technology should also use the Windows Installer Service for installation to the default “program files” directory and should be able to silently install and uninstall.

c) Applications designed for normal end users shall run in the standard user context without elevated system administration privileges.

C.6. The Contractor shall establish processes and procedures for continuous monitoring of

Contractor systems that contain TSA data by ensuring all such devices are monitored by, and report to, the TSA Security Operations Center (SOC). The Contractor shall perform monthly Nessus scans on servers that contain TSA data, and shall send monthly scan results to the TSA Information Assurance

Division (IAD)

D. Risk Management Framework

D.1. The Security Authorization and Ongoing Authorization Process in accordance with NIST SP 800-

37 and SP 800-137 (current versions) is a requirement for all TSA IT systems, including general support systems (e.g., standard TSA desktop, general network infrastructure, electronic mail, etc.), major applications and development systems (if connected to the operational network or processing, storing, or transmitting government data). These processes are documented in the NIST Risk Management

Framework. Ongoing Authorization is part of Step 6 “Monitoring” of the Risk Management Framework.

All NIST and DIACAP guidance are publicly available; TSA and DHS security policy is disclosed upon contract award.

D.2. A written authority to operate (ATO) granted by the TSA Authorizing Official (AO) is required prior to processing operational data or connecting to any TSA network. The contractor shall provide all necessary system information for the security authorization effort.

D.3. TSA will assign a security category to each IT system compliant with the requirements of Federal

Information Processing Standards (FIPS) 199 and assign security controls to those systems consistent with FIPS 200.

D.4. Unless the AO specifically states otherwise for an individual system, the duration of any

Accreditation will be dependent on the FIPS 199 rating and overall residual risk of the system; the length can span up to 36 months.

D.5. The Security Authorization Package contains documentation required for Security

Authorizations and Ongoing Authorization. The package shall contain the following security documentation: 1) Security Assessment Report (SAR) 2) Security Plan (SP) or System Security

Authorization Agreement (SSAA), 3) Contingency Plan, 4) Contingency Plan Test Results, 5) Federal

Information Processing Standards (FIPS) 199 Security Categorization, 6) Privacy Threshold Analysis (PTA),

7) E-Authentication, 8) Security Assessment Plan (SAP), 9)Authorization to Operate (ATO) Letter, 10)

Plan of Action and Milestones (POA&M), and 11) Ongoing Authorization Artifacts as required by the DHS

Ongoing Authorization Methodology (current version). The SA package shall document the specific procedures, training, and accountability measures in place for systems that process personally identifiable information (PII). All security compliance documents will be reviewed and approved by the

Chief Information Security Officer (CISO) and the Information Assurance and Cyber Security Division

(IAD), and accepted by the Contracting Officer upon creation and after any subsequent changes, before they go into effect.

D.6. The contractor shall support the successful remediation of all identified system weaknesses and vulnerabilities.

E. Contingency Planning

E.1. The Contractor shall develop and maintain a Contingency Plan (CP), to include a Continuity of

Operation Plan (COOP), to address circumstances whereby normal operations are disrupted.

E.2. The Contractor shall ensure that contingency plans are consistent with template provided in the

DHS Information Assurance Compliance System Tool. If access has not been provided initially, the contractor shall use the DHS 4300A Sensitive System Handbook, Attachment K, IT Contingency Plan

Template.

E.3. The Contractor shall identify and train all TSA personnel involved with COOP efforts in the procedures and logistics of the disaster recovery and business continuity plans.

E.4. The Contractor shall ensure the availability of critical resources and facilitate the COOP in an emergency situation.

E.5. The Contractor will test their CP annually.

E.6. The Contractor shall record, track, and correct any CP deficiency and any deficiency correction that cannot be accomplished within one month of the annual test will be elevated to the Information

Assurance and Cyber Security Division (IAD).

E.7. The Contractor shall retain records of the annual CP testing for review during periodic audits.

E.8. The Contractor shall ensure the CP addresses emergency response, backup operations, and recovery operations.

E.9. The Contractor shall have an Emergency Response Plan that includes procedures appropriate to fire, flood, civil disorder, disaster, bomb threat, or any other incident or activity that may endanger lives, property, or the capability to perform essential functions.

E.10. The Contractor shall have a Backup Operations Plan that includes procedures and responsibilities to ensure that essential operations can be continued if normal processing or data communications are interrupted for any reason for an unacceptable period of time as described in the

Statement of Work.

E.11. The Contractor shall have a Post-disaster Recovery Plan that includes procedures and responsibilities to facilitate rapid restoration of normal operations at the primary site or, if necessary, at a new facility following the destruction, major damage, or other major interruption at the primary site.

E.12. The Contractor shall ensure all TSA data (e.g., mail, data servers, etc.) is incrementally backed up on a daily basis.

E.13. The Contractor shall ensure a full backup of all network data occurs as required by the system’s availability security categorization impact rating per TSA Information Assurance policy.

E.14. The Contractor shall ensure all network…