SOW_-_Fleet_Data_v.2_06.30.2015.doc

Statement of Work (SOW)

Transportation Vetting System Technology Refresh Fleet Data June 2015 Version 2

STATEMENT OF WORK (SOW)

1. INTRODUCTION

The Office of Information Technology (OIT) is the component of the Transportation Security Administration (TSA) which enables global transportation security by providing world class information technologies and services. The Transportation Vetting System (TVS) is a mission-critical, National Security system which operates 24 hours per day, 7 days per week.

2. SCOPE AND PERIOD OF PERFORMANCE

TVS requires fleet data for all commercial airlines, worldwide. TVS is subscribing to a fleet data subscription to enrich the data currently available in the system. The data will enable TVS users’ to perform analysis and trending based on specific characteristics of aircraft. … The scope of this contract is limited to the fleet data itself. TVS will ingest and process the fleet data; therefore, software applications that provide fleet data will not meet the technical requirements.

The Contractor shall provide the fleet data in pipe-delimited text files. All data shall be updated monthly and files shall be posted to a HyperText Transport Protocol Secure (HTTPS) site, where they will be retrieved by TVS. Files shall be named consistently each month, and file names shall include the date of delivery.

Help Desk support shall be provided for fleet data questions. Support shall be provided by email and/or phone during the Contractor’s standard business hours. The Contractor shall respond to requests for support within one business day.

The Contractor shall provide a notification procedure for reporting known data errors to TVS (i.e., if the Contractor identifies an error with data that has been delivered, the Contractor shall notify TVS of the error). The Contractor shall provide a notification procedure for planned and unplanned delays in monthly data delivery.

The base period of performance of this SOW begins on the date of award and ends twelve months after the date of award. The period of performance may be extended via four, twelve-month option periods.

Within 14 days of contract award, the COR and Contractor shall negotiate the date for initial file delivery and the schedule for monthly updates.

3. TECHNICAL REQUIREMENTS

The Contractor shall deliver the data in a pipe-delimited text format. The solicitation requires each bidder to provide a sample file which is representative of the file to be provided in the subscription. This sample file will be evaluated as part of the technical evaluation prior to award.

3.1 Airline Fleet Data Provide Airline Fleet Data, delivered in a pipe-delimited text format on a monthly basis. Data file shall contain, at a minimum:

· Aircraft Type Code

· Aircraft Status Code

· Aircraft Class

· Aircraft Serial Number

· Production Line Number

· Manufacturer

· Date of Manufacture

· Delivery Date

· Delivery Status

· Registration / Tail No. (i.e. ‘N’ Number)

· Registration Country

· Engine Manufacturer

· Engine Model

· Engine Type

· Quantity of Engines

· Lease or Owned Indicator

· Lease Expiry Date

· Total Hours

· Category (Cargo, PAX or Business Class)

· OAG Equipment Type

· F41 Equipment Type

· Equipment Model

· Equipment Group

· Seating Capacity

· Seating by Service Class

· Operator Category

· Operator Name

· Operator IATA Code

· Operator ICAO Code

· Operator Country Code (ISO-2)

· Operator Region Code

· Registered Owner Category

· Registered Owner Name

· Registered Owner IATA Code

· Registered Owner ICAO Code

· Beneficiary Owner Name

· Sublessor Category

· Sublessor Name

· Sublessor IATA Code

· Sublessor ICAO Code

· Previous Owner Category

· Previous Owner Name

· Previous Owner IATA Code

· Previous Owner ICAO Code

· Activity Date

· Activity Status

· Remark

· Minimum Flight Crew

· Max Range

3.5 Delivery Delivery of data is not required until agreed upon by the COR & the Contractor 14 days after contract award. TSA will retrieve the data files from the vendor's HyperText Transport Protocol Secure(HTTPS) site. Government must be provided access to the HTTPS site and data files must be initially available for download by the date negotiated by the COR and the Contractor (within 14 days of contract award).

4.0

508 COMPLIANCE

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, 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 standards have been identified:

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.

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 COTR and determination will be made in accordance with DHS MD 4010.2. DHS has identified the following exceptions that may apply:

36 CFR 1194.2(b) – (COTS/GOTS products), When procuring a product, each agency shall procure products which comply with the provisions in this part when such products are available in the commercial marketplace or when such products are developed in response to a Government solicitation. Agencies cannot claim a product as a whole is not commercially available because no product in the marketplace meets all the standards. If products are commercially available that meet some but not all of the standards, the agency must procure the product that best meets the standards.

When applying this standard, all procurements of EIT shall have documentation of market research that identify a list of products or services that first meet the agency business needs, and from that list of products or services, an analysis that the selected product met more of the accessibility requirements than the non-selected products as required by FAR 39.2. Any selection of a product or service that meets less accessibility standards due to a significant difficulty or expense shall only be permitted under an undue burden claim and requires approval from the DHS Office on Accessible Systems and Technology (OAST) in accordance with DHS MD 4010.2.

36 CFR 1194.3(b) – Incidental to Contract, all EIT that is exclusively owned and used by the contractor to fulfill this work statement does not require compliance with Section 508. This exception does not apply to any EIT deliverable, service or item that will be used by any Federal employee(s) or member(s) of the public. This exception only applies to those contractors assigned to fulfill the obligations of this work statement and for the purposes of this requirement, are not considered members of the public.

36 CFR 1194.3(f) – Back Office, applies to any EIT item that will be located in spaces frequented only by service personnel for maintenance, repair, or occasional monitoring of equipment. This exception does not include remote user interfaces that are accessible outside the enclosed “space”.

5.0 SECURITY OF SYSTEMS HANDLING PERSONALLY IDENTIFIABLE INFORMATION AND PRIVACY INCIDENT REPONSE

(a) Definitions.

“Breach” (may be used interchangeably with “Privacy Incident’) as used in this clause means the loss of control, compromise, unauthorized disclosure, unauthorized acquisition, unauthorized access, or any similar situation where persons other than authorized users, and for other than authorized purpose, have access or potential access to Personally Identifiable Information, in usable form whether physical or electronic.

“Personally Identifiable Information (PII)” as used in this clause means any information that permits the identity of an individual to be directly or indirectly inferred, including any other information that is linked or linkable to that individual regardless of whether the individual is a citizen of the United States, legal permanent resident, or a visitor to the United States.

Examples of PII include: 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), Internet protocol addresses, biometric identifiers (e.g., fingerprints), 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 Personally Identifiable Information (Sensitive PII)” as used in this clause is a subset of Personally Identifiable Information, which if lost, compromised or disclosed without authorization, could result in substantial harm, embarrassment, inconvenience, or unfairness to an individual. , Complete social security numbers (SSN), alien registration numbers (A-number) and biometric identifiers (such as fingerprint, voiceprint, or iris scan) are considered Sensitive PII even if they are not coupled with additional PII. Additional examples include any groupings of information that contains an individual’s name or other unique identifier plus one or more of the following elements:

(1) Driver’s license number, passport number, or truncated SSN (such as last 4 digits)

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

(3) Citizenship or immigration status

(4) Financial information such as account numbers or Electronic Funds Transfer Information

(5) Medical Information

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

Other Personally Identifiable information may be “sensitive” depending on its context, such as a list of employees with less than satisfactory performance ratings or an unlisted home address or phone number. In contrast, a business card or public telephone directory of agency employees contains Personally Identifiable Information but it is not sensitive.

(b) Systems Access. Work to be performed under this contract requires the handling of Sensitive PII. The contractor shall provide the Government access to, and information regarding systems the contractor operates on behalf of the Government under this contract, when requested by the Government, as part of its responsibility to ensure compliance with security requirements, and shall otherwise cooperate with the Government in assuring compliance with such requirements. Government access shall include independent validation testing of controls, system penetration testing by the Government, Federal Information Security Management Act (FISMA) data reviews, and access by agency Inspectors General for its reviews.

(c) Systems Security. In performing its duties related to management, operation, and/or access of systems containing Sensitive PII under this contract, the contractor, its employees and subcontractors shall comply with applicable security requirements described in DHS Sensitive System Publication 4300A or any replacement publication and rules of conduct as described in TSA MD 3700.4

In addition, use of contractor-owned laptops or other media storage devices to process or store PII is prohibited under this contract until the contractor provides, and the contracting officer in coordination with CISO approves, written certification by the contractor that the following requirements are met:

(1) Laptops employ encryption using a NIST Federal Information Processing Standard (FIPS) 140-2 or successor approved product;

(2) The contractor has developed and implemented a process to ensure that security and other applications software are kept current;

(3) Mobile computing devices utilize anti-viral software and a host-based firewall mechanism;

(4) When no longer needed, all removable media and laptop hard drives shall be processed (i.e., sanitized, degaussed, or destroyed) in accordance with DHS security requirements.

(5) The contractor shall maintain an accurate inventory of devices used in the performance of this contract;

(6) Contractor employee annual training and rules of conduct/behavior shall be developed, conducted/issued, and acknowledged by employees in writing. Training and rules of conduct shall address at minimum:

(i) Authorized and official use;

(ii) Prohibition against use of personally-owned equipment to process, access, or store Sensitive PII;

(iii) Prohibition against access by unauthorized users and unauthorized use by authorized users; and

(iv) Protection of Sensitive PII;

(7) All Sensitive PII obtained under this contract shall be removed from contractor-owned information technology assets upon termination or expiration of contractor work. Removal must be accomplished in accordance with DHS Sensitive System Publication 4300A, which the contracting officer will provide upon request. Certification of data removal will be performed by the contractor’s Project Manager and written notification confirming certification will be delivered to the contracting officer within 15 days of termination/expiration of contractor work.

(d) Data Security. Contractor shall limit access to the data covered by this clause to those employees and subcontractors who require the information in order to perform their official duties under this contract. The contractor, contractor employees, and subcontractors must physically secure Sensitive PII when not in use and/or under the control of an authorized individual, and when in transit to prevent unauthorized access or loss. When Sensitive PII is no longer needed or required to be retained under applicable Government records retention policies, it must be destroyed through means that will make the Sensitive PII irretrievable.

The contractor shall only use Sensitive PII obtained under this contract for purposes of the contract, and shall not collect or use such information for any other purpose without the prior written approval of the contracting officer. At expiration or termination of this contract, the contractor shall turn over all Sensitive PII obtained under the contract that is in its possession to the Government.

(e) Breach Response. The contractor agrees that in the event of any actual or suspected breach of PII (i.e., loss of control, compromise, unauthorized disclosure, access for an unauthorized purpose, or other unauthorized access, whether physical or electronic), it shall immediately, and in no event later than one hour of discovery, report the breach to the contracting officer, the Contracting Officer’s Technical Representative (COTR), and the TSA Director of Privacy Policy & Compliance (TSAprivacy@dhs.gov). The contractor is responsible for positively verifying that notification is received and acknowledged by at least one of the foregoing Government parties.

(f) Personally Identifiable Information Notification Requirement. The contractor has in place procedures and the capability to promptly notify any individual whose Sensitive PII was, or is reasonably believed to have been, breached, as determined appropriate. The method and content of any notification by the contractor shall be coordinated with, and subject to the prior approval of the Government, based upon a risk-based analysis conducted by the Government in accordance with DHS Privacy incident Handling Guidance. Notification shall not proceed unless the Government has determined that: (1) notification is appropriate; and (2) would not impede a law enforcement investigation or jeopardize national security.

Subject to Government analysis of the breach and the terms of its instructions to the contractor regarding any resulting breach notification, a method of notification may include letters to affected individuals sent by first class mail, electronic means, or general public notice, as approved by the Government. At minimum, a notification should include: (1) a brief description of how the breach occurred; (2) a description of the types of personal information involved in the breach; (3) a statement as to whether the information was encrypted or protected by other means; (4) steps an individual may take to protect themselves; (5) what the agency is doing, if anything, to investigate the breach, to mitigate losses, and to protect against any further breaches; and (6) point of contact information identifying who affected individuals may contact for further information.

In the event that a PII breach occurs as a result of the violation of a term of this contract by the contractor or its employees, the contractor shall, as directed by the contracting officer and at no cost to the Government, take timely action to correct or mitigate the violation, which may include providing notification and/or other identity protection services to affected individuals for a period not to exceed 12 months from discovery of the breach. Should the Government elect to provide and/or procure notification or identity protection services in response to a breach, the contractor will be responsible for reimbursing the Government for those expenses.

(g) Pass-Through of Security Requirements to Subcontractors. The contractor agrees to incorporate the substance of this clause, its terms and requirements, in all subcontracts under this contract, and to require written subcontractor acknowledgement of same. Violation by a subcontractor of any provision set forth in this clause will be attributed to the contractor.

6.0 Security Policy and Architecture

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

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

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

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

1.5 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 application assets (e.g., application servers, domain controllers, Information Assurance (IA) tools, etc.) will be incrementally backed up as required to eliminate loss of critical audit data and allow for restoration and resumption of normal operations within one hour.

E.15. The Contractor shall ensure sufficient backup data to facilitate a full operational recovery within one business day at either the prime operational site or the designated alternate site will be stored at a secondary location determined by the local element disaster recovery plan.

E.16. The Contractor shall ensure that data at the secondary location is current as required by the system’s availability security categorization impact rating.

E.17. The Contractor shall ensure the location of the local backup repository and the secondary backup repository is clearly defined, and access controlled as an Information Security Restricted Area (ISRA).

E.18. The Contractor shall adhere to the DHS Security Architecture Guidance Volume 1: Network and System Infrastructure for the layout of the file systems, or partitions, on a system’s hard disk impacting the security of the data on the resultant system. File system design shall:

· Separate generalized data from operating system (OS) files

· Compartmentalize differing data types

· Restrict dynamic, growing log files or audit trails from crowding other data.

E.19. The contractor shall adhere to the DHS Security Architecture Guidance Volume 1: Network and System Infrastructure Design for the management of mixed data for OS files, user accounts, externally-accesses data files and audit logs.

1.6 F. Program Performance

F.1. The Contractor shall comply with requests to be audited and provide responses within three business days to requests for data, information, and analysis from the TSA Information Assurance and Cyber Security Division (IAD) and management, as directed by the Contracting Officer.

F.2. The Contractor shall provide support during the Information Assurance and Cyber Security Division (IAD) audit activities and efforts. These audit activities may include, but are not limited to the following: requests for system access for penetration testing, vulnerability scanning, incident response and forensic review.

1.7 G. Federal Risk and Authorization Management Program (FedRAMP)

If a vendor is to host a system with a Cloud Service Provider, the following shall apply:

G.1. FedRAMP Requirements: Private sector solutions will be hosted by a Joint Authorization Board (JAB) approved Infrastructure as a Service (IaaS) Cloud Service Provider (CSP) (http://cloud.cio.gov/fedramp/cloud-systems) and shall follow the Federal Risk and Authorization Management Program (FedRAMP) requirements. The Cloud Service Provider shall adhere to the following in addition to the FedRAMP requirements: Identity and entitlement access management shall be done through Federated Identity; SSI and PII shall be encrypted in storage and in transit as it is dispersed across the cloud; Sanitization of all TSA data shall be done as necessary at the IaaS, PaaS or SaaS levels; Cloud bursting shall not occur; TSA data shall be logically separated from other cloud tenants; All system administrators shall be U.S. citizens; TSA data shall not leave the United States; The cloud internet connection shall be behind a commercial Trusted Internet Connection that has EINSTEIN 3 Accelerated (E3A) capabilities deployed. These include but are not limited to the analysis of network flow records, detecting and alerting to known or suspected cyber threats, intrusion prevention capabilities and under the direction of DHS detecting and blocking known or suspected cyber threats using indicators. The E3A capability shall use the Domain Name Server Sinkholing capability and Email filtering capability allowing scans to occur destined for .gov networks for malicious attachments, Uniform Resource Locators and other forms of malware before being delivered to .gov end-users.

G.2. Private Sector System Requirements: TSA shall conduct audits at any time on the private sector systems, and the system shall be entered into the TSA FISMA Inventory as a system of record using the Control Implementation Summary (CIS) provided by the Cloud Service Provider. Security artifacts shall be created and maintained in the DHS Information Assurance Compliance Tool (IACS). The private sector systems are required to go through the Security Authorization Process and the Risk Management Framework in accordance the Federal Information Systems Management Act and NIST SP 800-37 Rev. 1. The cloud internet connection shall be behind a commercial Trusted Internet Connection that has EINSTEIN 3 Accelerated (E3A) deployed. Security event logs and application logs shall be sent to the TSA SOC. Incidents as defined in the TSA Information Assurance 1400.3 Management Directive and Handbook shall be reported to the TSA SPOC 1-800-253-8571. DHS Information Security Vulnerability Management Alerts and Bulletins shall be patched within the required time frames as dictated by DHS.

1.8 H. Information Assurance Policy

H.1. All services, hardware and/or software provided under this task order must be compliant with DHS 4300A DHS Sensitive System Policy Directive, DHS 4300A Sensitive Systems Handbook., TSA MD 1400.3 Information Technology Security Policy, TSA Information Assurance Handbook and Technical Standards.

H.2. The Contractor solution shall follow all current versions of TSA and DHS policies, procedures, guidelines, and standards, which will be provided by the Contracting Officer, including but not limited to:

· DHS Sensitive Systems Policy Directive (PD) 4300A

· DHS 4300A Sensitive Systems Handbook

· DHS National Security Systems Policy Directive (PD) 4300B

· DHS 4300B National Security Systems Handbook·

· TSA MD 1400.3 Information Technology Security

· TSA Information Assurance Handbook

· TSA Technical Standards

· DHS IT Security Architecture Guidance Volumes 1, 2 and 3

· DHS/TSA Systems Engineering Lifecycle (SELC)

· DHS Performance Plan (current fiscal year)

· DHS Ongoing Authorization Methodology (current version)

· OMB M-10-28, M-14-03

H.3. Authorized use of TSA IT systems and resources shall be in accordance with the TSA Information Assurance Handbook.

H.4. The contractor shall complete TSA Form 251 and TSA Form 251-1 for sensitive or accountable property. The contractor shall email the completed forms to TSA-Property@dhs.gov and include a hard copy with the shipment.

1.9 I. Data Stored/Processed at Contractor Site

I.1. Unless otherwise directed by TSA, any storage of data must be contained within the resources allocated by the Contractor to support TSA and may not be on systems that are shared with other commercial or government clients.

1.10 J. Remote Access

J.1. The Contractor remote access connection to TSA networks shall be considered a privileged arrangement for both Contractor and the Government to conduct sanctioned TSA business. Therefore, remote access rights must be expressly granted, in writing, by the TSA Information Assurance and Cyber Security Division (IAD).

J.2. The Contractor remote access connection to TSA networks may be terminated for unauthorized use, at the sole discretion of TSA.

1.11 K. Interconnection Security Agreement

If the service being supplied requires a connection to a non-DHS, Contractor system, or DHS system of different sensitivity, the following shall apply:

K.1. Interconnections between DHS and non-DHS IT systems shall be established only through controlled interfaces and via approved service providers. The controlled interfaces shall be accredited at the highest security level of information on the network. Connections with other Federal agencies shall be documented based on interagency agreements; memoranda of understanding/agreement, service level agreements or interconnection service agreements.

K.2. ISAs shall be reissued every three (3) years or whenever any significant changes have been made to any of the interconnected systems.

K.3. ISAs shall be reviewed and updated as needed as a part of the annual FISMA self-assessment.

1.12 L. SBU Data Privacy and Protection

L.1. The contractor must satisfy requirements to work with and safeguard Sensitive Security Information (SSI), and Personally Identifiable Information (PII). All support personnel must understand and rigorously follow DHS and TSA requirements, policies, and procedures for safeguarding SSI and PII. Contractor personnel will be required to complete Annual online training for SSI, Informational Security, and TSA Privacy training, which take approximately one hour each.

L.2. The Contractor shall be responsible for the security of i) all data that is generated by the contractor on behalf of the TSA, ii) TSA data transmitted by the contractor, and iii) TSA data otherwise stored or processed by the contractor regardless of who owns or controls the underlying systems while that data is under the contractor’s control. All TSA data, including but not limited to PII, sensitive security information (SSI), sensitive but unclassified (SBU), and critical infrastructure information (CII), shall be protected according to DHS and TSA security policies and mandates.

L.3. TSA will identify IT systems transmitting unclassified/SSI information that will require protection based on a risk assessment. If encryption is required, the following methods are acceptable for encrypting sensitive information:

1. FIPS 197 (Advanced Encryption Standard (AES)) 256 algorithm and cryptographic modules that have been validated under FIPS 140-2. (current version)

2. National Security Agency (NSA) Type 2 or Type 1 encryption. (current version)

3. Public Key Infrastructure (PKI) (see paragraph 5.5.2.1 of the Department of Homeland Security (DHS) 4300A Sensitive Systems Handbook). (current version)

L.4. The contractor shall maintain data control according to the TSA security level of the data. Data separation shall include the use of discretionary access control methods, VPN encryption methods, data aggregation controls, data tagging, media marking, backup actions, and data disaster planning and recovery. Contractors handling PII must comply with TSA MD 3700.4, Handling Sensitive Personally Identifiable Information (current version).

L.5. Users of TSA IT assets shall adhere to all system security requirements to ensure the confidentiality, integrity, availability, and non-repudiation of information under their control. All users accessing TSA IT assets are expected to actively apply the practices specified in the TSA Information Assurance Handbook and applicable IT Security Technical Standards.

L.6. The contractor shall comply with Sensitive Personally Identifiable Information (Sensitive PII) disposition requirements stated in the TSA Information Assurance Handbook, applicable Technical Standards and TSA MD 3700.4, Handling Sensitive Personally Identifiable Information.

L.7. The Contractor shall ensure that source code is protected from unauthorized access or dissemination.

1.13 M. Disposition of Government Resources

M.1 At the expiration of the contract, the contractor shall return all TSA information and IT resources provided to the contractor during the contract, and provide a certification that all assets containing or used to process TSA information have been sanitized in accordance with the TSA MD 1400.3, TSA Information Assurance Handbook and Technical Standards. The contractor shall certify in writing that sanitization or destruction has been performed. Sanitation and destruction methods are outlined in the NIST Special Publication 800-88 Guidelines for Media Sanitization, and TSA Technical Standard 046 IT Media Sanitization and Disposition. The contractor shall email signed proof of sanitization to the COTR. In addition, the contractor shall provide a master asset inventory list that reflects all assets, government furnished equipment (GFE) or non-GFE that were used to process TSA information.

1.14 N. Special Considerations and Circumstances (if applicable)

1.14.1 Security Program Plan

N.1 For major agency Information Technology (IT) infrastructure support ranging in the total estimated procurement value (TEPV) of about $100 million or above or per TSA management’s request, the contractor may need to provide, implement, and maintain a Security Program Plan (SPP) based on the templates provided by the TSA Information Assurance and Cyber Security Division (IAD). This plan shall describe the processes and procedures that will be followed to ensure the appropriate security of IT resources that are developed, processed, or used under this contract. At a minimum, the contractor’s SPP shall address the contractor’s compliance with the controls described in NIST SP 800-53 (current version). The security controls contained in the plan shall meet the requirements listed in the TSA Information Assurance Handbook, Technical Standards and the DHS Sensitive Systems Policy Directive and Handbook 4300A (current versions).

N.2 The SPP shall be a living document. It will be reviewed and updated semi-annually to address new processes, procedures, technical or federally mandated security controls and other contract changes that affect the security of IT resources under contract.

N.3 The SPP shall be submitted within 30 days after contract award. The SPP shall be consistent with and further detail the approach contained in the offeror’s proposal or quote that resulted in the award of this contract and in compliance with the requirements stated in this clause.

N.4 The SPP, as accepted by the Contracting Officer and Information System Security Officer (ISSO), shall be incorporated into the contract as a compliance document. The Contractor shall comply with the accepted plan.

For Official Use Only

Source Selection Sensitive