Attachment1-Statement of Objectives (SOO) - Amendment 3 (Tracked Changes).docx

AUTOMATE FIELD DATA COLLECTION ACTIVITIES

REQUIREMENTS & CAPABILITIES ANALYSIS (RCA)

INNOVATION TASK FORCE (ITF)

STATEMENT OF OBJECTIVES (SOO)

AUTOMATE FIELD DATA COLLECTION ACTIVITIES

REQUIREMENTS & CAPABILITIES ANALYSIS (RCA)

INNOVATION TASK FORCE (ITF)

STATEMENT OF OBJECTIVES (SOO)

70T04024CSOP7573N001 – A00003

April 15,May 20, 2024

Background:

The mission of the Transportation Security Administration (TSA) is to protect the Nation’s transportation systems to ensure freedom of movement for people and commerce. TSA created the Innovation Task Force in 2016 to cultivate innovation in transportation security and enhance screening operations by accelerating the introduction of new technologies into live airport environments and other transportation venues. As part of TSA’s Requirements and Capabilities Analysis office, ITF fosters innovation by integrating key stakeholders to identify critical problem statements and capability gaps, source and demonstrate emerging technologies, gather performance data and conduct quarterly collaboration meetings with industry. ITF is seeking industry information and solutions related to the below Automated Field Data Collection Activities problem statement that was submitted to ITF in April 2023 by RCA’s Analysis and Engineering Directorate, Rates & Standards Branch:

Automate Field Data Collection Problem Statement: The proliferation of screening technologies has increased the number of field data collection events necessary to characterize system performance. TSA lacks a solution to collect various operational data in-lieu of deploying expensive data collection teams.

Purpose:

To collect and analyze current Automated Field Data Collection capabilities to inform decisions necessary to execute ITF’s mission of enhancing TSA’s screening operations.

Scope:

The Contractor shall deliver an automated prototype to collect, analyze and report field data to include, but not limited to, checkpoint screening and checked baggage screening in a field environment. In the subsequent contracts award(s), the TSA intends to include optional development that to further refine proposed prototypes to meet the TSA’s evolving requirements. For the purposes of this project, field data will be defined as any data not currently captured by Transportation Security Equipment (TSE). Examples of this data include, but are not limited to: time spent by a passenger at the Travel Document Checker (TDC) podium, divest locations, and during secondary screening.

Period of Performance & Type of Contract:

The Period of Performance is intended to be one year for each awarded contract. This award will establish a Non-FAR, Firm Fixed Price (FFP) contract through the DHS Commercial Solution Opening Pilot Program (CSOP).

Place of Performance:

Data Collection shall be performed onsite at one location to be determined by ITF after award in a Checkpoint or Checked Baggage screening area. Data Analysis is to be conducted at Contractor’s facility, at an address provided by the Contractor.

Clearance Level:

All personnel providing support for this effort shall maintain or obtain a suitability clearance for the duration of the data collection and analysis phases of this effort.

Minimum Performance Objectives:

The below requirements are required to enable TSA assessment of the prototype in a live operational environment.

Develop a prototype for the application of Automated Field Data Collection Contractor shall develop a comprehensive strategy and proposed Concept of Operations (CONOPS) for the use of Automated Field Data Collection capabilities. Any proposed CONOPS shall be approved by TSA.

Contractor shall implement the proposed CONOPS created in Section 7(A) (1). As an Automated Field Data Collection prototype. The prototype application will automatically collect, identify, catalog, store and report field data. The prototype application will be installed by the contractor at the place of performance for testing and data capture.

Training The Contractor shall provide training material on the functionality, features, and use of the Automated Field Data Collection prototype. This material shall be reviewed by the User and TSA Training & Development (T&D). The User and T&D will provide guidance on any requisite modification needed for use in training.

TSA and the Contractor shall have an adjudication meeting to agree upon training material changes, if needed.

The Contractor shall make agreed upon requisite training changes prior to beginning data collection/before installing the prototype.

The Contractor shall design and produce all curricula/training materials (e.g., slide decks, handout materials, knowledge check assessments, etc.) necessary to conduct end-user training sessions.

The Contractor shall conduct no less than three (3) and up to 12 end user training sessions of 30 minutes each, as needed.

The Contractor shall conduct no less than two (2) and up to five (5) system administrator training sessions to TSA staff at the chosen location.

The prototype system shall not require training for passengers.

Installation and Removal of Equipment The Contractor shall facilitate the installation and removal of all Equipment, Cabling and Power Cords needed for the operation of equipment directly with local TSA airport staff in coordination with ITF.

The Contractor shall install the prototype and validate operational capability no more than 30 days and no less than seven (7) days prior to the Burn in Date.

The Contractor shall remove all prototype equipment from the demonstration location within 15 days of completion of data collection unless expressly approved and mutually agreed upon by the COR, the Contractor, and Local TSA.

TSA will determine the level of security assessment required on the prototype.

The installation for a typical mod-set in screening checkpoint or checked baggage screening location shall not require more than two users.

The prototype shall enable a government user (data collector) to set up, configure the tools, and be ready for data capture in less than eight (8) hours.

The prototype shall not require/modify any data, power or routing infrastructure requirements of the current checkpoint or checked baggage screening environment.

Data Capture All data captured by the Automated Field Data Collection prototype system shall be stored, transferred and transmitted on TSA-approved devices and follow all applicable TSA IT requirements. No data captured shall be stored, transferred or transmitted outside of the TSA-approved network or on non-TSA-approved devices.

Analysis and Reporting

The prototype shall provide the following reports:

The data captured shall be subject to weekly Data Authentication by TSA during the data collection.

All data captured using the Automated Field Data Collection prototype shall be analyzed to generate a comprehensive report with a datasheet compatible with excel and summary statistics or as otherwise directed by the COR .

The Contractor shall provide daily and weekly quick look/status reports during the data collection.

The Contractor shall provide a draft report to the COR within 30 calendar days following the completion of data collection.

TSA shall provide feedback within 30 calendar days of receipt of the draft report.

The Contractor and TSA shall hold a comment adjudication meeting if requested by TSA within 14 calendar days of providing feedback to Contractor.

The draft report shall be considered final if no response comments are provided.

Overall Functionality: The below data points are currently captured by TSA. The prototype submitted shall automate these types of data:

The prototype shall require minimal additional steps from the TSO.

The prototype shall not interfere with normal/regular checkpoint security screening operations and procedures.

The prototype shall allow for data collection activities for at least 16 continuous hours without interruption.

The prototype shall function autonomously and may provide capability to augment records with manually collected data as necessary using a device such as a smartphone or tablet to collect additional attribute data as necessary.

The prototype shall allow for the recording and association of additional passenger attributes, e.g., Explosive Trace Detection (ETD) screening results and items of interest. This may be done post processing, after automated image and data collection or in real time.

The prototype shall allow recall and retrieval of passenger checkpoint information to allow for further analysis and error handling.

The prototype shall delineate between fully-loaded peak conditions where there is a constant queue of passengers or items (accessible properties or checked bags) present before the operation being evaluated. For X-ray screening, the general rule is at least 2-3 passengers actively divesting and at least 2 or 3 in queue preparing to divest.

The prototype shall automatically record and provide the capability to report cycle time, throughput, and attribute data for passenger and accessible property screening. The installation of additional sensors, cameras and systems are allowed to have a self-sufficient system. This includes:

Timestamp Cycle time of the passengers at the Travel Document Checker (TDC) and TDC process cycle time. Additional data may include ID type (iI.e. driver’s license, passport) Timestamp Cycle time of passengers at the divest station and divest process cycle time. Additional data may include the number of bins/items divested per passenger.

Timestamp Cycle time of passengers at the Walk-Through Metal Detector (WTMD) and WTMD process cycle time. Additional data may include WTMD alarm rates.

Timestamp Cycle time of passengers at the Advanced Imaging Technology (AIT) and AIT process cycle time. Additional data may include pat-downalarm rates and location of alarms.

Timestamp Cycle time of passengers at secondary search (e.g. pat downs, bag searches, wheelchair/motorized scooter inspection, etc.) and secondary search cycle time for passengers that alarm the primary passenger screening methods. Additional data may include alarm rates, alarming items, and secondary search types.

Timestamp Cycle time and number of passenger bins at recompose positions. Additional data may include the number of bins/items recomposed per passenger.

Timestamp Cycle time and number of passenger bins in Automated Passenger Screening System (APSS) (via Computed Tomography (CT) X-ray image analysis).

Timestamp Cycle time for image presentation and cycle time for adjudication. Additional data may include the number and type of alarms, alarm clear rates, suspect rates, and latency, where applicable.

Capability to capture picture(s) of passenger’s accessible property at diversion to secondary screening. This is an objective performance measure and not a baseline requirement of the prototype.

Credential Authentication Technology (CAT)/Boarding Pass Scanner (BPS) The prototype shall leverage commercial tools available to capture passenger information from their boarding pass.

The prototype shall collect information at TDC not requiring any additional information from the passenger.

The prototype shall only use the minimal data for the purpose of data collection to avoid capturing Sensitive Personally Identifiable Information (PII) from passengers.

Divest Station The prototype shall capture and segregate passengers in the applicable divest station.

The prototype shall associate passengers to their bins at the divest station.

Primary Screening TSE The process supporting the prototype shall be able to manually import images and FDRS data from Advanced Technology (AT) and Computed Tomography (CT) technologies, to the extent the original equipment manufacturers (OEM) are in agreement and compliance.

The prototype shall not modify any image content.

The prototype shall capture user, machine decision, bounding boxes, etc., for the applicable bag content.

The prototype shall not connect to TSE during normal screening operations.

Alarm Resolution Capture The prototype shall capture data related to alarm resolution and provide mechanisms or tools for the user to augment data to include, but not limited to, record alarm resolution steps for final adjudication of an alarm object.

The prototype shall allow a user to capture alarm object images.

The prototype shall allow a user to capture via Graphical User Interface (GUI) and record advanced alarm resolution timestamps and TSO/ Transportation Security Specialist for Explosives (TSSE) actions for final adjudication of an alarm object.

System Performance The prototype shall accurately capture passenger timestamps idle and cycle time at TDC, WTMD, AIT, etc., and enable a simplistic/user friendly process to validate the captured data.

Safety The prototype shall be safe to use by TSOs and passengers in a regular operational checkpoint environment.

The prototype shall use Underwriter Laboratories (UL) compliant Commercial Off the Shelf (COTS) elements.

Cyber All prototype devices shall have password protected user-level access.

Any wireless connectivity shall be air gapped.

The prototype shall not support real-time data analysis. Any sensors gathering data will send the data at a later time to an analysis server system to create the requested data views. Data captured by Transportation Security Equipment (TSE) is not meant to support real-time analysis.

Privacy The prototype shall not collect or store any Personally Identifiable Information (PII) to include facial images/biometrics.

Scalability The prototype design shall allow for the collection of data for a single or multiple lanes.

The prototype shall be modular enough to be scaled up or scaled down for different configurations.

Optional Performance Objectives:

The below requirements may be provided in addition to the requirements set forth in Section 7.0, but are not required:

Analysis and Reporting The prototype may provide an alarm resolution analyses report – cycle times, TSE-used, types of alarming items, alarm resolution methods, process durations, and container types.

Overall Functionality The prototype may identify any TSE used in primary and secondary screening, as well as Transportation Security Officer (TSO) actions and decisions made during primary and secondary screening, and items within passenger’s accessible property.

The prototype may allow for the recording and association of additional passenger attributes, e.g., Explosive Trace Detection (ETD) screening results and items of interest. This may be done post processing, after automated image and data collection, or in real time.

Integration with TSE: The process supporting the prototype may be able to manually import images and FDRS data from Advanced Technology (AT) and Computed Tomography (CT) technologies, to the extent the original equipment manufacturers (OEM) are in agreement and compliance.

The prototype may capture user, machine decision, bounding boxes, etc., for the applicable bag content.

Alarm Resolution Capture The prototype may capture data related to alarm resolution and provide mechanisms or tools for the user to augment data to include, but not limited to, record alarm resolution steps for final adjudication of an alarm object.

The prototype may allow a user to capture alarm object images.

The prototype may allow a user to capture via Graphical User Interface (GUI) and record advanced alarm resolution timestamps and TSO/ Transportation Security Specialist for Explosives (TSSE) actions for final adjudication of an alarm object.

Section 508 Requirements:

Section 508 of the Rehabilitation Act (classified to 29 U.S.C. § 794d) requires that when Federal agencies develop, procure, maintain, or use information and communications technology (ICT), it shall be accessible to people with disabilities. Federal employees and members of the public with disabilities must be afforded access to and use of information and data comparable to that of Federal employees and members of the public without disabilities.

All products, platforms and services delivered as part of this work statement that, by definition, are deemed ICT shall conform to the revised regulatory implementation of Section 508 Standards, which are located at 36 C.F.R. § 1194.1 & Appendixes A, C & D, and available at https://www.ecfr.gov/cgi-bin/text-idx?SID=e1c6735e25593339a9db63534259d8ec&mc=true&node=pt36.3.1194&rgn=div5. In the revised regulation, ICT replaced the term electronic and information technology (EIT) used in the original 508 standards. ICT includes IT and other equipment.

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

Section 508 Requirements for Technology Products Section 508 applicability to Information and Communications Technology (ICT): Automated Field Data Collection Report Applicable Exception: N/A Authorization #: N/A Applicable Functional Performance Criteria: Does not apply Applicable 508 requirements for electronic content features and components (including but not limited to Electronic reports; Electronic training materials): All requirements in E205 apply, including all WCAG 2.0 Level A and AA Success Criteria apply as specified in E205, except 2.4.1 Bypass Blocks, 2.4.5 Multiple Ways, 3.2.3 Consistent Navigation, and 3.2.4 Consistent Identification Applicable 508 requirements for software features and components: Does not apply Applicable 508 requirements for hardware features and components: Does not apply Applicable 508 requirements for support services and documentation: All requirements in Chapter 6 apply Section 508 Deliverables Section 508 Accessibility Conformance Reports: For each ICT item offered through this contract (including commercially available products, and solutions consisting of ICT that are developed or modified pursuant to this contract), the Offeror shall provide an Accessibility Conformance Report (ACR) to document conformance claims against the applicable Section 508 standards. The ACR shall be based on the Voluntary Product Accessibility Template Version 2.0 508 (or successor versions). The template can be found at https://www.itic.org/policy/accessibility/vpat. Each ACR shall be completed by following all of the instructions provided in the template, including an explanation of the validation method used as a basis for the conformance claims in the report.

(End of clause)

DHS and TSA Enterprise Architecture (December 2022):

The Contractor shall ensure that all architectural artifacts including but not limited to solutions, business, Data, IT elements for legacy TSE, Information Systems Security Agreements (ISSAs), System Design documents (SDDs), deliverables, and services are aligned and compliant with the current DHS and TSA Enterprise Architecture, The Common Approach to Federal Enterprise Architecture, the Technology Business Management (TBM) Taxonomy, and Federal Information Technology Acquisition Reform Act (FITARA).

All solutions and services shall meet DHS and TSA Enterprise Architecture policies, standards, and procedures. Specifically:

DHS and TSA Enterprise Architecture policies, standards, and procedures.

Homeland Security Enterprise Architecture (HLS EA) and TSA EA requirements.

TSA and DHS IT Security, Cloud, Infrastructure (including Network), Application/Systems, Information/Data, Performance, and Business Architecture policies, directives, guidelines, standards, segment architectures and reference architectures.

TSA functional capabilities TSA operational capabilities TSA lines of business TSA business processes TSA funding sources TBM Taxonomy for IT cost transparency All software and tools that are used to build, develop, or deploy IT solutions for TSA, shall leverage the TSA NextGen Architecture (NGA) Technology Stack known as “The Kit”. In accordance with TSA CIO Priority 2.1 “Modernize, Simplify, Reduce and Enforce TSA IT and Data Toolkit,” use of “the Kit” will achieve modernization and simplification, with the ultimate goal of reducing the current TSA Technology Footprint.

This includes new TSE and Legacy TSE that utilizes IT software, services, or equipment including embedded IT elements such as network switches, routers, in printers, etc.

All solutions shall implement and leverage TSA information and data standards as defined and approved per TSA policy.

All solution architectures and services (e.g., Application, System, Network, Security, Information/Data, Cloud) shall be reviewed and approved by TSA EA as part of the TSA SELC (System Engineering Life Cycle) review process and in accordance with TSA IT Governance Management Directive 1400.20 with applicable DHS and TSA IT governance policies, directives, and processes. This includes the Solution Engineering Review (SER), Preliminary Design Review (PDR) and Critical Design Review (CDR) stage gates. The required design artifacts include solution approach document, the PDR document, and the System Design Document (SDDs) as directed by EAD. Successful completion of the PDR/CDR stages results in an approved architecture which is required before proceeding to development. An approved architecture is also a necessary critical step in receiving an Authority to Operate (ATO). All implementations shall follow the approved solution architecture/design without deviation. Any changes, to either the prior approved solution and/or prior approved design that are identified during subsequent SELC phases, including testing, implementation and deployment, shall undergo additional EA review prior to proceeding.

TSA Offices acquiring Enterprise architecture type services at segment or solution levels shall engage and collaborate with the TSA Enterprise Architecture Division (EAD) to ensure strategic alignment of people, process, information, and technology and comply with enterprise level architecture governance, artifacts and standards.

The Contractor shall engage domain architect(s) in EAD before SELC Obtain Phase, i.e. during SELC Need or “Analyze and Select” Phase.

The Contractors shall collaborate with the EA domain architect(s) to deliver the required design artifacts and desired outcome under the guidance.

The Contractor shall provide architecture and system/application data and models in prescribed formats to be stored in TSA’s Enterprise Architecture Repository.

In accordance with the TSA Cloud Strategy 2.0, April 2019, TSA’s approach to cloud computing and governance of migration to the cloud, the contractor shall ensure that the cloud solutions utilize the SaaS (Software as a Service) model as its primary approach to cloud implementation, and also, when necessary will use Platform as a Service (PaaS) or Infrastructure as a Service (IaaS). The contractor shall adhere to the principles of cloud strategy to systematically retire or replace legacy applications by use of an integrated approach to cloud planning, architecture, hybrid deployment, and operation.

Applicability of Internet Protocol Version 6 (IPv6) to DHS-related components (networks, infrastructure, and applications) specific to individual acquisitions shall be in accordance with the DHS Enterprise Architecture (per OMB Memorandum M-21-07, November 2020) regardless of whether the acquisition is for modification, upgrade, or replacement. All EA related component acquisitions shall be IPv6 compliant as defined in the U.S. Government Version 6 (USGv6) Profile (National Institute of Standards and Technology (NIST) Special Publication 500-267) and the corresponding declarations of conformance defined in the USGv6 Test Program.

The Contractor shall develop, use, and dispose of TSA information and data assets following the TSA governance processes established by the Enterprise Information/Data Governance Board (EIDGB), in compliance with the DHS Enterprise Data Governance and Management MD (Management Directive) 103-01.

TSA information and data assets include but are not limited to the TSA Data Catalog, TSA information and data standards, TSA Data Management Plan, TSA data sets (including open data sets for public consumption), TSA information and data stored in TSA repositories, TSA information and data in systems and applications (internal and external), and TSA information exchanges.

All TSA information and data, and all solutions that capture, store, use and provide TSA information and data shall comply with the Geospatial Data Act (GDA) of 2018 (P.L. 115-254) that requires agencies to foster efficient management of geospatial data/information, technologies, and infrastructure through enhanced coordination among Federal, state, local, and tribal governments, along with private sector and academia.

Description information for all data assets shall be submitted to the TSA Enterprise Architecture Team, who will be responsible for coordination with DHS, and for review, approval and insertion into the TSA Data Reference Model and Enterprise Architecture Repository.

In addition to the Federal Acquisitions Regulations (FAR) Subpart 27.4 – ‘Rights in Data and Copyrights’ and Section 35.011 detailing technical data delivery, the contractor shall provide all TSA-specific data in a format maintaining pre-existing referential integrity and data constraints, as well as data structures in a format understandable to TSA. Examples of data structures can be defined as, but not limited to:

Data models containing entities and attributes, identifying authoritative and trusted data sources, and depicting relationship mapping and, or linkages Metadata information to define data definitions Detailed data formats, type, and size Delineations of the referential integrity (e.g., primary key/foreign key) of data schemas, structures, and or taxonomies Information exchange specifications All TSA-specific data shall be delivered in a secure and timely manner to TSA. Data security is defined within the ‘Requirements for Handling Sensitive, Classified, and/or Proprietary Information’, section of this SOW (Statement of Work), SOO (Statement of Objectives) and PWS (Performance Work Statement). This definition complies with not only the delivery of data, but also maintaining TSA-specific data within a non-TSA or DHS proprietary system.

All metadata shall be pre-defined upon delivery to TSA. Metadata shall be delivered in a format that is readily interpretable by TSA (e.g., metadata shall be extracted from any metadata repository that is not utilized by TSA and delivered in a TSA approved manner). Metadata shall also provide an indication of historical version, the most current data to be used, as well as frequency of data refreshes.

The contractor shall provide a Data Asset Repository Profile (DAR) and Data Management Plan (DMP) to EA using EA provided template before the preliminary/critical design review. The DAR and DMP include conceptual and logical data models, data dictionaries, data asset profile, and other artifacts pertinent to the project’s data.

TSA adheres to the DHS NIEM (National Information Exchange Model) First policy and standards outlined in the DHS Memorandum, “Adoption of the National Information Exchange Model within the Department of Homeland Security,” dated May 3, 2019. All TSA information and data exchanges shall be NIEM compliant. All TSA solutions that leverage TSA information and data exchanges shall be NIEM compliant.

(End of clause)

CYBERSECURITY POLICY FOR TSA GOVERNMENT ACQUISITIONS (JULY 2023):

General Security Requirements:

All authorized, cleared and vetted personnel (i.e., federal employees; and primary, subcontractor, and/or 3rd party vendors or contractors) supporting or doing business per agreement with TSA (either directly or indirectly) shall comply with applicable cybersecurity or information assurance (IA) policies as stated in the DHS Policy Directive 4300A, “Information Technology System Security Program, Sensitive Systems, version 13.3, Feb 23, 2023 (hereafter known as DHS 4300A); DHS National Security Systems Policy Directive 4300B Version 10.1, November 21, 2018 for classified systems (hereafter known as DHS 4300B); TSA MD 1400.3 Information Technology Security (ITS); TSA Information Assurance (IA) Handbook; supplemental Technical Standards (TSs) and Standard Operating Procedures (SOPs); TSA Cloud Computing Security Handbook (CCSH); and the DOD Cloud Computing Security Requirements Guide (CC SRG).

The Contractor shall comply with Federal, Department of Homeland Security (DHS) and Transportation Security Administration (TSA) security, sensitive information handling, and privacy guidelines in effect at the time of the award of the contract, as well as those requirements that may be added during the contract.

The Contractor shall perform periodic reviews to ensure compliance with cybersecurity, information security and privacy requirements.

The Contractor shall comply with proper DHS and TSA security controls to ensure that the Government's security requirements are met. These controls are described in DHS 4300A, TSA MD 1400.3 ITS and the TSA Information Assurance (IA) Handbook security policy documents and are based on the current National Institute of Standards and Technology (NIST) Special Publication (SP) 800-32 Rev 2 and 800-53 Rev 5 standards.

The Contractor shall include this guidance in all subcontracts at any tier where the subcontractor is performing the work defined in the Statement of Work (SOW), Performance Work Statement (PWS), Statement of Objective (SOO).

The Contractor shall ensure all of its staff members have the required level of approved security clearance commensurate with the sensitivity of the information being accessed, stored, processed, transmitted or otherwise handled by the system or required to perform the work stipulated by the contract. At a minimum, all Contractor staff shall be subjected to a Public Trust background check and be granted a Public Trust clearance before access to any system or other TSA resources as granted.

The Contractor shall sign a DHS Form 11000-6 Non-Disclosure Agreement (NDA) within thirty (30) calendar days of the contract start date.

The Contractor shall not release, publish, or disclose agency information to unauthorized personnel, and shall protect such information in accordance with the provisions of pertinent laws, regulations, and policies governing the confidentiality of sensitive information.

The Contractor shall ensure its staff follow all policies and procedures governing cybersecurity, physical, environmental, and information security described in the various TSA regulations pertaining thereto, and the specifications, directives, and manuals for conducting work to generate the products as required by the contract. Personnel shall be responsible for the physical security of their work area and government furnished equipment (GFE) issued to the contractor under the terms of the contract.

The Contractor shall make all system information and documentation produced (in support of the contract) available to TSA upon request.

Training Requirements:

All newly-arrived Contractor employees requiring system access shall receive initial “Organizational Security Fundamentals (OSF)” training within 60 days of assignment to the contract via the Online Learning Center (OLC). The COR shall initiate and facilitate this access. Refresher training shall be completed annually thereafter. Another required OLC cybersecurity training course is the “Cybersecurity for TSA System Users (TSA-CYBRSCRTY-SYSTM-USRS)” training and would be the official TSA-wide course developed in accordance with mandated policy to safeguard TSA’s mission and assets. It is the annual course that all users shall take and the one leveraged against FISMA requirements. (Note: This course replaced the older animated “IT Security Awareness” training of the past).

The Contractor shall complete any TSA-related Privacy training on an annual basis.

Role-Based training is required for contract employees with Significant Security Responsibility (SSR), whose job proficiency is required for overall network security within TSA, and shall be in accordance with DHS and TSA policy. The contractor shall be notified if they have a position with Significant Security Responsibilities.

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

Cybersecurity and privacy training supplied by the Contractor shall meet standards established by NIST and set forth in DHS and TSA security policy.

The Contractor shall maintain an accurate and up-to-date list of all vetted contractor employees who have completed training and shall submit this list to the Contracting Officer’s Representative (COR) upon request, or during DHS/TSA onsite validation visits performed on a periodic basis.

The contractor shall ensure its employees review, understand, and sign the TSA Form 1403 Computer and Wireless Mobile Device Access Agreement (CAA) prior to accessing any IT systems.

Configuration Management (hardware/software/applications):

Hardware or software configuration changes shall be in accordance with the current DHS Information Security Performance Plan, 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)/Executive Director for Information Assurance and Cybersecurity Division (IAD) shall be informed of and aware of all configuration changes to the TSA IT environment including, but not limited to: systems, hardware, software, applications, infrastructure architecture, infrastructure assets, and end user assets. The TSA IAD POC shall approve any Request for Change (RFC) prior to any development activity occurring for that change and shall define the security requirements for the requested change. The COR shall provide access to the DHS Information Security Performance Plan.

The Contractor shall ensure all application, software and/or configuration patches and/or Requests for Change (RFC) have approval by the Technical Discussion Forum (TDF), Change Control Board (CCB) and lab regression testing prior to controlled change release under the security policy document, TSA Management Directive (MD) 1400.3 Information Technology Security (ITS) and TSA Information Assurance (IA) Handbook, unless immediate risk requires immediate intervention. Approval for immediate intervention (i.e., emergency change) requires approval of the TSA CISO, CCB co-chairs, and the appropriate Operations Manager, at a minimum.

The Contractor shall ensure all sites, facilities or operational functions impacted by patching are compliant within 14 days of change approval and release.

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 authorized products that have been carefully analyzed, reviewed, evaluated and validated, as appropriate, in accordance with the following:

The NIST FIPS validation program.

The National Security Agency (NSA)/NIST, National Information Assurance Partnership (NIAP) Evaluation and Validation Program.

The International Common Criteria for Information Security Technology Evaluation Mutual Recognition Agreement.

US Government Department of Defense/Department of Homeland Security, Security Technical Implementation Guides (STIGs) The provider of information technology shall certify all applications are fully functional, safe, secure and operate correctly as intended on systems using the US DoD Security Technical Implementation Guides (STIGs) and in accordance with DHS and TSA guidance.

DoD STIGs/SRG:

https://public.cyber.mil/stigs/ DHS Sensitive Systems Configuration Guidance:

https://dhsconnect.dhs.gov/org/comp/mgmt/ocio/ciso/Pages/sscg.aspx The standard installation, operation, maintenance, management, updates and/or patching of software shall not alter the configuration settings from the approved USGCB configuration. The information technology shall also use the Windows Installer Service for installation to the default “program files” directory and shall be able to discretely install and uninstall.

Applications designed for general end users shall run in the general user context without elevated system administration privileges.

The Contractor shall establish processes and procedures for continuous monitoring of Contractor systems that contain TSA data/information by ensuring all such devices are monitored by, and report to, the TSA Security Operations Center (SOC). The Contractor shall perform monthly security scans on servers that contain TSA data, and shall send monthly scan results to the TSA IAD.

Risk Management Framework (RMF):

The Security Authorization (SA) and Ongoing Authorization (OA) processes, in accordance with recent NIST SP 800-37 Rev 2 (Risk Management Framework for Information Systems and Organizations: A System Life Cycle Approach for Security and Privacy) and SP 800-137 (Information Security Continuous Monitoring (ISCM) for Federal Information Systems and Organizations) are required for all TSA IT systems, including General Support Systems (e.g., standard TSA desktop, general network infrastructure, electronic mail), 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 (RMF) and the Ongoing Authorization is part of Step 6 “Monitoring” of the RMF. All NIST guidance is publicly available; TSA and DHS security policy is disclosed upon contract award with some exceptions, which are public facing (i.e., DHS Security and Training Requirements for Contractors).

A written Authorization 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 in support of the Security Authorization (SA) process.

TSA shall assign a security category to each IT system compliant with the requirements of Federal Information Processing Standards (FIPS) Pub 199 Standards for Security Categorization of Federal Information and Information Systems impact levels and assign security controls to those systems consistent with FIPS Pub 200 Minimum Security Requirements for Federal Information and Information Systems methodology.

Unless the AO specifically states otherwise for an individual system, the duration of any accreditation shall be dependent on the FIPS 199 rating and overall residual risk of the system; the length can span up to 36 months.

The Security Authorization (SA) Package contains documentation required for Security Authorizations and Ongoing Authorization. The package shall contain the following security documentation as required by the DHS Ongoing Authorization Methodology:

Security Assessment Report (SAR), Security Plan (SP), Contingency Plan, Contingency Plan Test Results, Federal Information Processing Standards (FIPS) 199 Security Categorization, Privacy Threshold Analysis (PTA), E-Authentication, Security Assessment Plan (SAP), Authorization to Operate (ATO) Letter, Plan of Action and Milestones (POA&M), and Ongoing Authorization Artifacts 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 shall be reviewed and approved by the CISO and the IAD, and accepted by the Contracting Officer (CO) upon creation and after any subsequent changes, before they go into effect. Note: The CO shall not alter or remove any documentation or language once approved by IAD or authorized members of its staff. Ongoing Authorization artifacts include monthly TRigger Accountability Log (TRAL), monthly operating system scan results, application scans as directed, updated control allocation table (CAT), and associated memos as directed. All steps in the DHS Mandated tool or System of Record shall be completed correctly, thoroughly and in a timely manner for all steps of the RMF.

The Contractor shall support the successful remediation of all identified system weaknesses and vulnerabilities that are identified as a result of the aforementioned security review process.

The Contractor shall submit and analyze monthly operating system vulnerability scans for the DHS Information Security Performance Plan FISMA Scorecard. Vulnerabilities not remediated are generated into Plan of Action and Milestone (POA&Ms) after 30 days.

Contingency Planning:

The Contractor shall develop and maintain a Contingency Plan (CP), to include a Continuity of Operation Plan (COOP), to address circumstances whereby normal operations may be disrupted and thus requiring activation of the CP and/or COOP. The contractor’s CP/COOP responsibility relates only to the approved system(s) they provide or operate under contract.

The Contractor shall ensure that contingency plans are consistent with template provided in DHS Mandated System of Record. If access has not been provided initially, the contractor shall use the DHS 4300A, Attachment K IT Contingency Plan Template.

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.

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

The Contractor shall test their CP annually and retain records of the annual CP testing for review during periodic audits.

The Contractor shall record, track, and correct any CP deficiency; any deficiency correction that cannot be accomplished within one month of the annual test shall be elevated to IAD management.

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

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

The Contractor shall have a Backup Operations Plan (BOP) that includes procedures and responsibilities to ensure that essential operations can be continued if normal processing or data communications are interrupted for any reason.

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.

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

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

The Contractor shall ensure all network application assets (e.g., application servers, domain controllers, Information Assurance (IA) tools, etc.) shall be incrementally backed up as required to eliminate loss of critical audit data and allow for restoration and resumption of normal operations within one (1) hour.

The Contractor shall ensure backup of data to facilitate a full operational recovery within one (1) business day at either the prime operational site or the designated alternate/backup site in accordance with local disaster recovery plan.

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

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

The Contractor shall adhere to the DHS IT Security Architecture Guidance 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 The Contractor shall adhere to the DHS IT Security Architecture Guidance for the management of mixed data for OS files, user accounts, externally-accesses data files and audit logs.

Program Performance and Audit:

The Contractor shall comply with requests to be audited and provide responses within three (3) business days to requests for data, information, and analysis from the TSA IAD and management, as directed by the CO.

The Contractor shall provide support during IAD audit activities and efforts. These audit activities shall include, but are not limited to: requests for system access for penetration testing, vulnerability scanning, incident response and forensic review.

Upon completion of monthly security scans, findings shall be documented and categorized as High, Moderate, or Low based on their potential impact to the System IT security posture. The Contractor shall provide TSA with estimates of the total engineering service hours required to support the remediation of open POA&M items. High security findings shall be remediated first in 45 days or less; Moderate security findings shall be remediated in 60 days or less, and Low security findings shall be remediated in 90 days or less. The Contractor shall work with the TSA System Information Systems Security Officer (ISSO) and the respective CO and/or COR, as well as IAD and the System Owner (as required) to prioritize and plan for the remediation of open POA&Ms. The TSA System ISSO shall maintain all security artifacts and perform Ongoing Authorization (per NIST 800-137 and DHS TSA requirements) and Continuous Diagnostics and Mitigation (CDM) (per OMB M-14-03) activities to ensure active compliance with security requirements. Specific POA&M guidance and information can be found in the SOP 1401 Plan of Action and Milestone (POA&M) Process, as well as the DHS 4300A Attachment H Plan of Action and Milestones (POA&M) Process Guide.

Federal Risk and Authorization Management Program (FedRAMP):

If a vendor is to host a system with an approved Cloud Service Provider (CSP), the CSP and shall adhere to the following:

Comply with Federal Agency cloud requirements per CCSH;

Identity and entitlement access management shall be done through Federated Identity;

SSI, PII and SPII 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 properly cleared and vetted U.S. citizens;

TSA data shall not leave the United States; and The cloud internet connection shall route via an approved DHS Trusted Internet Connection (TIC) 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 with malicious attachments, Uniform Resource Locators and other forms of malware before being delivered to *.gov end-users.

Private Sector System Requirements: TSA shall conduct audits at any time on approved private sector systems, and the system shall be entered into the TSA FISMA Inventory as a system of record (SOR) using the Control Implementation Summary (CIS) provided by the Cloud Service Provider. Security artifacts shall be created and maintained in the DHS Mandated System of Record.