Attachment 2 - ITAR_Terms-ConditionsFinal.pdf

As of 03/31/2026

On-Person Screening and Alarm Resolution

Broad Agency Announcement (BAA)

70T04026BAA7573N001

Attachment 2

Terms & Conditions

1.0 Terms and Conditions

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

1.1 Section 508 Requirements for Technology Products

• Section 508 applicability to Information and Communications Technology

(ICT): Sample IT Solution o Applicable Exception: N/A Authorization #: N/A o Applicable Functional Performance Criteria: All functional performance criteria in Chapter 3 apply to when using an alternative design or technology that results in substantially equivalent or greater accessibility and usability by individuals with disabilities than would be provided by conformance to one or more of the requirements in Chapters 4 and 5 of the Revised 508 Standards, or when Chapters 4 or 5 do not address one or more functions of ICT.

o Applicable 508 requirements for electronic content features and components (including but not limited to Internet and Intranet website;

Electronic documents; Electronic forms; Electronic document templates;

Electronic emergency notifications; Electronic surveys; Electronic reports;

Electronic training materials; Multi-media (video/audio); Interactive maps):

https://uscode.house.gov/view.xhtml?req=(title:29%20section:794d%20edition:prelim)%20OR%20(granuleid:USC-prelim-title29-section794d)&f=treesort&edition=prelim&num=0&jumpTo=true https://www.ecfr.gov/cgi-bin/text-idx?SID=e1c6735e25593339a9db63534259d8ec&mc=true&node=pt36.3.1194&rgn=div5 https://www.ecfr.gov/cgi-bin/text-idx?SID=e1c6735e25593339a9db63534259d8ec&mc=true&node=pt36.3.1194&rgn=div5

All requirements in E205 apply, including all WCAG 2.0 Level A and AA

Success Criteria apply as specified in E205.

o Applicable 508 requirements for software features and components (including but not limited to Web, desktop, server, mobile client applications; Electronic content and software authoring tools and platforms;

Software infrastructure; Service Offerings): All requirements in Chapter 5 apply, including all WCAG 2.0 Level A and AA Success Criteria, 502

Interoperability with Assistive Technology, 503 Application, 504 Authoring

Tools o Applicable 508 requirements for hardware features and components (including but not limited to Computers & laptops; Servers;

Printers and Copiers): All requirements in Chapter 4 apply o Applicable 508 requirements for support services and documentation: All requirements in Chapter 6 apply

1.2 Section 508 Requirements for Technology Services

• When providing installation, configuration or integration services for ICT, the

Contractor shall not reduce the original ICT item’s level of Section 508 conformance prior to the services being performed.

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

• When providing maintenance upgrades, substitutions, and replacements to ICT, the

Contractor shall not reduce the original ICT’s level of Section 508 conformance prior to upgrade, substitution or replacement. The agency reserves the right to request an

Accessibility Conformance Report (ACR) for proposed upgrades, substitutions and replacements prior to acceptance. The ACR should be created using the Voluntary

Product Accessibility Template Version 2.2 508 (or successor versions). The template can be located at https://www.itic.org/policy/accessibility/vpat

• When providing Platform as a Service (PaaS) or Software as a Service (SaaS), the contractor shall ensure services conform to the applicable Section 508 standards

(including the requirements in Chapter 5 for software and WCAG Level A and AA

Level 2.0 success criteria for web and software. When the requirements in Chapter 5 do not address one or more software functions, the Contractor shall ensure conformance to the Functional Performance Criteria specified in Chapter 3.) The agency reserves the right to request an Accessibility Conformance Report (ACR) for

PaaS and SaaS offerings. The ACR shall be created using the Voluntary Product

Accessibility Template Version 2.2 508 (or successor versions). The template can be located at https://www.itic.org/policy/accessibility/vpat.

• When providing cloud hosting services (Infrastructure as a Service, Platform as a

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

• The Contractor shall ensure cloud hosting services do not reduce the level of Section

508 conformance for ICT migrated by DHS to the cloud hosting environment.

https://www.itic.org/policy/accessibility/vpat https://www.itic.org/policy/accessibility/vpat

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

• When developing or modifying web based and electronic content components, except for electronic documents and non-fillable forms provided in a Microsoft Office or

Adobe PDF format, the Contractor shall demonstrate conformance to the applicable

Section 508 standards (including WCAG 2.0 Level A and AA Success Criteria) by conducting testing using the DHS Trusted Tester for Web Methodology Version 5.0 or successor versions, and shall ensure testing is conducted by individuals who are certified by DHS on version 5.0 or successor versions (e.g. “DHS Certified Trusted

Testers”). The Contractor shall provide the Trusted Tester Certification IDs to DHS upon request. Information on the DHS Trusted Tester for Web Methodology Version

5.0, related test tools, test reporting, training, and tester certification requirements is published at https://www.dhs.gov/trusted-tester.

• When developing or modifying electronic documents and non-fillable forms provided in a Microsoft Office or Adobe PDF format, the Contractor shall demonstrate conformance to the applicable Section 508 standards (including WCAG Level A and

AA Level 2.0 Success Criteria) by conducting testing using the test methods published under “Accessibility Tests for Documents” at https://www.dhs.gov/compliance-test-processes.

• When developing or modifying ICT deliverables that contain the ability to automatically generate electronic documents and forms in Microsoft Office and

Adobe formats, or when the capability is provided to enable end users to design and author web based electronic content (i.e. surveys, dashboards, charts, data visualizations, etc.), the Contractor shall demonstrate the ability to ensure electronic content outputs conform to the applicable Section 508 standards (including WCAG

2.0 Level A and AA Success Criteria). The Contractor shall demonstrate conformance by conducting testing and reporting test results based on representative sample outputs. For outputs produced as Microsoft Office and Adobe PDF file formats, the Contractor shall use the test methods published under “Accessibility

Tests for Documents”, which are published at https://www.dhs.gov/compliance-test-processes. For outputs produced as web based electronic content, the Contractor shall use the DHS Trusted Tester for Web Methodology Version 5.0, or successor versions. This methodology is published at https://www.dhs.gov/trusted-tester.

• When developing or modifying software functions of ICT, the Contractor shall demonstrate conformance to the applicable Section 508 standards (including the requirements in Chapter 5 and WCAG 2.0 Level A and AA Success Criteria). When the requirements in Chapter 5 do not address one or more software functions, the

Contractor shall demonstrate conformance to the Functional Performance Criteria specified in Chapter 3. The Contractor shall use a test process capable of validating conformance to all applicable Section 508 standards for software functionality delivered pursuant to this contract. The Contractor may utilize the DHS Trusted

Tester Methodology for Web and Software Version 4.0 as a component of the overall test process used. This version of the test process provides partial test coverage of the

Section 508 standards that apply to software. If the Contractor uses this test process, https://www.dhs.gov/trusted-tester https://www.dhs.gov/compliance-test-processes https://www.dhs.gov/compliance-test-processes https://www.dhs.gov/compliance-test-processes https://www.dhs.gov/trusted-tester the Contractor shall address the test coverage gaps through additional test procedures. Information on the DHS Trusted Tester Methodology for Web and

Software Version 4.0, including coverage against the applicable Section 508 standards for software as well as gaps that need to be addressed through other test methods, related test tools, and training is published at https://www.dhs.gov/trusted-tester.

• When developing or modifying hardware components of ICT, including closed systems (for example – kiosks), the Contractor shall demonstrate conformance to the applicable Section 508 standards (including the Chapter 4 hardware requirements). Where the requirements in Chapters 4 do not address one or more functions of ICT, the Contractor shall demonstrate conformance to the Functional

Performance Criteria specified in Chapter 3. The Contractor shall use a test process capable of validating conformance to all applicable Section 508 standards for hardware functionality delivered pursuant to this contract.

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

1.3 Section 508 Deliverables

• Section 508 Test Plans: When developing or modifying ICT pursuant to this contract, the Contractor shall provide a detailed Section 508 Conformance Test Plan.

The Test Plan shall describe the scope of components that will be tested, an explanation of the test process that will be used, when testing will be conducted during the project development life cycle, who will conduct the testing, how test results will be reported, and any key assumptions.

• Section 508 Test Results: When developing or modifying ICT pursuant to this contract, the Contractor shall provide test results in accordance with the Section 508

Requirements for Technology Services provided in this solicitation.

• Section 508 Accessibility Conformance Reports: For each ICT item offered through this contract (including commercially available products, and solutions consisting of

ICT that are developed or modified pursuant to this contract), the Offeror shall provide an Accessibility Conformance Report (ACR) to document conformance claims against the applicable Section 508 standards. The ACR shall be based on the

Voluntary Product Accessibility Template Version 2.0 508 (or successor versions).

2.2 Cybersecurity Policy for TSA Government Acquisitions (November 2025)

A. General Security Requirements:

A.1. Special notice for program sponsors:

The following Cybersecurity policy requirements supersedes any inadvertent or deliberate contradiction in previous sections of this document. Program sponsors must ensure this section is thoroughly reviewed prior to initiating the Appendix G approval process.

A.2. 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

(hereinafter known as DHS 4300A) and Attachments; DHS National Security Systems Policy

Directive 4300B Version 10.1, November 21, 2018 for classified systems (hereinafter known as

DHS 4300B); TSA MD 1400.28 Information System Security Program (ISSP); TSA Information

System Security Program (ISSP) Policy Directive (PD) and TSA Organizational Defined

Parameter (ODP) spreadsheet; supplemental Technical Standards (TSs) and Standard Operating

Procedures (SOPs); TSA Cloud Computing Security Handbook (CCSH); the DOD Cloud

Computing Security Requirements Guide (CC SRG); and the NIST SP 800-53, “Security and

Privacy Controls for Information Systems and Organizations”, Rev 5 standards. This

Cybersecurity Policy document serves as a subset to the TSA PD. Additional DHS directives and security related guides for contractors can be found on DHS’ security policy site:

www.dhs.gov/publication/security-training-contract-policy.

A.3. 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.

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

A.5. 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.28 ISSP, the TSA ISSP PD and TSA ODP security policy documents and is mainly based on the current National Institute of Standards and Technology (NIST) Special

Publication (SP) 800-53 Rev 5 standards.

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

A.7. The Contractor shall ensure all 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.

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

A.9. 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.

http://www.dhs.gov/publication/security-training-contract-policy

A.10. 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.

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

B. Risk Management Framework (RMF):

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

B.2. Data Privacy and Protection: See SAFEGUARDING OF CONTROLLED

UNCLASSIFIED INFORMATION (JULY 2023) and INFORMATION TECHNOLOGY

SECURITY AWARENESS TRAINING (JULY 2023) for additional clauses.

a) The contractor shall satisfy requirements to work with and safeguard Controlled

Unclassified Information (CUI), which includes Sensitive Security Information (SSI), Personally Identifiable Information (PII), Sensitive Personally Identifiable Information

(SPII), and others (See Appendix G for other examples). All support personnel shall understand and rigorously follow DHS and TSA requirements, SSI Policies and

Procedures Handbook, and Privacy policies, and procedures for safeguarding SSI, PII and

SPII.

b) 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: CUI, PII, SPII, SSI, NSS, and Critical Infrastructure https://www.dhs.gov/dhs-security-and-training-requirements-contractors https://www.dhs.gov/dhs-security-and-training-requirements-contractors https://ustsa.sharepoint.com/:w:/r/sites/IntranetTS/Offices/OIT/ITAR2/3052.204-72SafeguardingControlledUnclassifiedInformation.docx?d=w0b68ceaa9c6442d49621ed086203c4ba&csf=1&web=1&e=eJfmU0 https://ustsa.sharepoint.com/:w:/r/sites/IntranetTS/Offices/OIT/ITAR2/3052.204-72SafeguardingControlledUnclassifiedInformation.docx?d=w0b68ceaa9c6442d49621ed086203c4ba&csf=1&web=1&e=eJfmU0 https://ustsa.sharepoint.com/:w:/r/sites/IntranetTS/Offices/OIT/ITAR2/IT_SecurityAwarenessTraining.docx?d=wf8f62664aeb1423f98309cb044d43e44&csf=1&web=1&e=KCUbwF https://ustsa.sharepoint.com/:w:/r/sites/IntranetTS/Offices/OIT/ITAR2/IT_SecurityAwarenessTraining.docx?d=wf8f62664aeb1423f98309cb044d43e44&csf=1&web=1&e=KCUbwF

Information (CII) shall be protected according to DHS and TSA security policies and mandates.

c) TSA shall identify IT systems transmitting any classified/unclassified/SSI information and requiring protection based on a risk assessment. If encryption is required, the following methods are acceptable for encrypting sensitive information:

a. FIPS 197 (Advanced Encryption Standard (AES)) 256 algorithm (or higher) and cryptographic modules that have been validated under FIPS 140-3.

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

c. Public Key Infrastructure (PKI) (see current DHS 4300A), key cards, biometrics, or in the case of multi-factor authentication MFA), some combination therein (See

Attachment U) Information Security Sensitive Systems Program Directive 4300A v 13.3, Feb 2023.

d) 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 SPII shall comply with TSA MD 3700.4, Handling Sensitive Personally Identifiable Information (current version).

e) 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 ISSP PD, TSA ODP, and applicable Technical Standards and SOPs.

f) The contractor shall comply with SPII disposition requirements stated in the TSA ISSP

PD, applicable Technical Standards, SOPs and TSA MD 3700.4, Handling Sensitive

Personally Identifiable Information.

g) The Contractor shall ensure all source code is protected from unauthorized access, alterations, or dissemination (see TSA ISSP PD, Technical Standard).

B.3. 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. Contractor shall provide all necessary system information in support of the Security Authorization (SA) process. The AO shall ensure all TSA information systems undergo security assessment and authorization and obtain an ATO prior to operation and deployment. This includes all systems

(including pilots) that connect to the TSA network or process TSA sensitive data. The AO shall grant a maximum of two Interim Authorizations to Operate (IATOs) for pilot systems and pilot systems shall not be connected to, or deployed as, an operational system until an ATO is issued.

ATOs for Pilot systems shall not exceed ninety (90) days and these systems shall be removed from the operational network unless an extension is approved by the AO.

B.4. 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. Additionally, compliance shall be in accordance with (IAW) NIST 800-60 Volume 2 and Volume 1: Appendices to Guide for

Mapping Types of Information and Information Systems to Security Categories.

B.5. 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.

B.6. The Security Authorization (SA) Package contains documentation required for SA and

Ongoing Authorization (OA). The package shall contain the following security documentation as required by the DHS OA Methodology:

a) Security Assessment Report (SAR)

b) Security Plan (SP)

c) Contingency Plan

d) Contingency Plan Test Results

e) Federal Information Processing Standards (FIPS) 199 Security Categorization

f) Privacy Threshold Analysis (PTA)

g) E-Authentication

h) Security Assessment Plan (SAP)

i) Authorization to Operate (ATO) Letter

j) Plan of Action and Milestone (POA&M)

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

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

B.8. 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.

B.9. Training Requirements:

a) All newly-arrived Contractor employees requiring system access shall receive initial cybersecurity 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 via OLC in accordance with FISMA mandated policy to safeguard TSA’s mission and assets.

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

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

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

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

f) 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 Representative (COR) upon request, or during DHS/TSA onsite validation visits performed on a periodic basis.

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

B.10. Configuration Management (hardware/software/applications):

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

https://hcm03.ns2cloud.com/sf/home?company=TSAHCM03&_s.crb=AIbxyeMmOvxpGQQgAy2ww6jr0X2b9%252bEVjeE%252fEYhw0QA%253d https://hcm03.ns2cloud.com/sf/home?company=TSAHCM03&_s.crb=AIbxyeMmOvxpGQQgAy2ww6jr0X2b9%252bEVjeE%252fEYhw0QA%253d

b) 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 MD 1400.28 ISSP, TSA PD and TSA

ODP, unless immediate risk requires immediate intervention.

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

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

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

f) US Government Department of Defense/Department of Homeland Security, Security

Technical Implementation Guides (STIGs):

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

a. DoD STIGs/SRG: https://public.cyber.mil/stigs/

b. DHS Sensitive Systems Configuration Guidance:

The standard installation, operation, maintenance, management, updates and/or patching of software shall not alter the configuration settings from the approved United States

Government Configuration Baseline | CSRC (nist.gov) (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.

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

https://public.cyber.mil/stigs/ https://usdhs.sharepoint.com/sites/dhsconnect/search/Pages/default.aspx?k=2%2E%09DHS%20Sensitive%20Systems%20Configuration%20Guidance#k=Configuration%20Guidance https://csrc.nist.gov/Projects/United-States-Government-Configuration-Baseline/FAQs#yJUv https://csrc.nist.gov/Projects/United-States-Government-Configuration-Baseline/FAQs#yJUv

g) The Contractor shall establish processes and procedures for continuous monitoring

(ConMon) 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 and other required assets that contain TSA data and shall send monthly scan results to the TSA IAD.

B.11. Contingency Planning:

a) 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. Additionally, the CP/COOP shall align to a Business Impact

Analysis (BIA), which establishes processes for identifying the critical information and services of TSA systems, IT assets, and the resources required to support them.

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

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

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

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

f) The Contractor shall have an up-to-date Emergency Response Plan (ERP), Backup

Operations Plan (BOP) and a Post-Disaster Recovery Plan (PDRP).

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

h) 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 ISSP PD.

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

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

B.12. Program Performance and Audit:

a) 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. These audits shall include, but are not limited to, requests for system access for penetration testing, vulnerability scanning, incident response and forensic review.

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

c) The Contractor shall afford DHS/TSA access to the Contractor’s facilities, installations, operations, documentation, databases, and personnel used in the performance of this contract.

B.13. Data Stored/Processed at Contractor Site:

a) Unless otherwise directed by TSA, any storage of data shall be contained within approved resources allocated by the Contractor (and approved by TSA) to support TSA and may not be on systems that are shared with other commercial or government entities or clients.

b) The AO shall approve the use of any contractor portable storage media on external systems.

c) The SO shall ensure the approved alternate storage site is physically secured to an equivalency of the primary storage site, using access controls.

B.14. Remote Access:

a) Any TSA-approved 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 shall be expressly granted, in writing, by the TSA AO.

b) Any unauthorized Contractor employee(s) remote access connection to TSA networks shall be terminated immediately at the sole discretion of TSA.

c) The Contractor shall use his or her federally issued and approved personal identity verification (PIV) credential/identification badge to access TSA resources to include IT applications and physical facility.

B.15. Disposition or decommission of Government Resources:

a) 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 signed certifications that all assets containing or used to process TSA information have been sanitized in accordance with the TSA MD 1400.28 ISSP, TSA ISSP PD, Technical Standards and

SOPs. The contractor shall certify in writing that sanitization or destruction has been performed. Sanitization and destruction methods are outlined in the NIST Special

Publication 800-88 Guidelines for Media Sanitization, TSA Technical Standard 046 IT

Media Sanitization and Disposition, and SOP 1400-503 IT Media Sanitization. The contractor shall email TSA, PM, CO, and COR a signed certification by the contractor’s designated senior security officer or senior official, signed proof of sanitization. In addition, the contractor shall provide the TSA CO a master asset inventory list that reflects all assets, government furnished equipment (GFE) or authorized non-GFE that were used to process and store TSA information.

B.16. Software Guidance:

The CO shall provide a listing of all TSA approved security software upon contract award. The approved security software listing is maintained by the IAD.

a) In support of the CDM objective to protect high value assets (HVAs) and information, the

TSA has acquired security tools to conduct Indicator of Compromise (IOC) scans within the mandated time frame. The Government shall provide the tool license and/or equipment for installation of tool agents on all TSA supported assets.

b) The contractor shall support efforts to allow for the IOC scanning mandate. This may include installation of tool servers and/or agents within each system’s environment and on all TSA supported assets. The Government shall provide the contractor with the tool server(s) that shall not belong to the contractor’s system boundary. The tool server shall be reachable from OneNet/TSANet over the Internet. The tool server(s) shall be properly configured to reach all assets with the tool agent installed on the network. Credentials

(service accounts) shall be provided for IOC scans and tool interrogation.

c) The contractor shall support or perform the installation of forensic software servlet agents on supported Operating Systems on all TSA contract supported devices and environments per TSA engineering, security, and configuration standards. The contractor shall test and upgrade the servlet agents as directed by the IAD.

d) The Government shall provide the contractor with a forensic software server that shall not belong to the contractor’s system boundary. The contractor shall support or perform the installation of the server. The server shall be reachable from TSANet over the

Internet and shall be primarily used for authentication and proxy functions. The server shall be properly configured to reach all assets with the agent installed on the network.

e) The contractor shall support efforts of incident response and forensic investigation. This includes authorization to connect TSA authorized equipment where the forensic software servlet agents are reachable to perform analysis.

f) The contractor shall install TSA-provided solution patches within two (2) days of issuance, or as directed by TSA CIO, and provide evidence of implementation to the TSA

ISSO.

g) End-of-Life (EOL) / End-of-Service (EOS):

1) The Contractor shall ensure that any hardware, software, or application that is procured develops a full lifecycle plan based on the vendor’s established life and service expectancy of the product and total cost of ownership. Any new or existing product that shall reach end-of-life (EOL)* within three (3) years and is part of a TSA FISMA IT System shall require development of a remediation, upgrade, replacement, and funding plan to remove the EOL item(s) from the TSA environment completely within that time frame. A plan of action and milestone

(POA&M) shall be submitted for risk acceptance to the TSA CISO to track remediation milestones appropriately.

*EOL / EOS - Defined as production and/or development, technical support, application updates, spare parts and security patches which are no longer available from the vendor.

B.17. Maintenance:

a) The Contractor shall ensure that the system, once operational, is properly and securely maintained and monitored, to include immediate response to critical security patches, routine maintenance windows to allow for system updates, and compliance with a defined configuration management process. All patches and system updates shall be properly tested and approved in a development environment before being implemented in the production environment.

b) The contractor shall perform customer support twenty-four (24) hours, seven (7) days a week (i.e., 24/7) within the Continental United States (i.e., CONUS) only.

C. Continuous Diagnostics and Mitigation:

C1. The Government, through a Continuous Monitoring as a Service (CMaaS) vendor, shall provide the contractor with GFE appliances and tools to support the implementation and maintenance of the Continuous Diagnostics and Mitigation (CDM) Solution. The tools shall be hosted on the DHS’ Infrastructure as a Service (IaaS) program. The Government, through the

CMaaS vendor, shall provide sensor kits, appliances, probes, and agents that shall be deployed on all contractor Information Systems supporting the TSA.

C2. The contractor shall support the installation (including rack and configuration) of sensor kits, appliances, probes, and agents on all TSA contract supported devices and environments per

TSA engineering, security, and configuration standards.

C3. The contractor shall configure/tune their existing endpoint security products to coexist with the identified products to ensure smooth and cohesive functionalities. Credentials (service accounts) shall be provided by the TSA CISO, or designee, for vulnerability scans and host interrogation.

C4. The Government, through the CMaaS vendor, shall provide the following support for operations and maintenance of the CDM solution sensor kits:

a) Patching (Controlled through a CMaaS Windows Server Update Service (WSUS))

b) Hardware troubleshooting & Risk Management (RMA)

c) Application maintenance (done from the Government/TSA Management Enclave)

d) Vulnerability scanning

C5. The contractor shall install TSA-provided CDM Solution patches within two (2) days of issuance, or as directed by TSA, and provide evidence of implementation to the TSA ISSO.

C6. The TSA CO (as approved and on behalf of the SO and TSA senior leadership) is authorized to provide technical direction to the contractor for the sole purpose of implementing the CDM Solution. If the technical direction results in any cost incurred by the contractor, for which the contractor shall seek reimbursement from the Government, the contractor shall identify the following information in any cost/price proposal to the Government: name of system owner, summary of the technical direction, date of the technical direction, purpose of the technical direction, summary of actions taken by the contractor, any other information the CO may require to further guide the directed change. The contactor shall receive approval from the

CO of the directed and approved change prior to incurring costs associated with the technical direction.

C7. Personal Identity Verification (PIV) and Login:

a) The Contractor shall use PIV credential/identification badges as the primary means to access TSA resources to include IT applications and physical facility. TSA network domain user account password expiration function shall be disabled when using PIV

Machine Based Enforcement (MBE). PINs for PIV card-enabled users shall not expire and shall have a minimum six-digit PIN when logging into the network using a PIV card.

b) The Contractor shall ensure newly developed information system(s) support PIV card authentication. The information system shall be capable to accept and electronically verify PIV credentials.

c) The Contractor shall employ information technology products on the FIPS 201-approved products list for Personal Identity Verification (PIV) capability implemented within organizational information systems.

d) The Homeland Security Presidential Directive 12 (HSPD-12) requires the use of the approved PIV credentials as the common means of authentication for access to DHS/TSA facilities, networks, and information systems. PIV credentials shall be used as the primary means of authentication for DHS/TSA sensitive IT systems. The Contractor shall use his or her federal issued PIV credentials to access TSA resources to include IT applications and physical facility.

e) The DHS/TSA Security Office shall be notified of all terminations/resignations within five (5) days of occurrence. The Contractor shall return to the Contracting Officer

Representative (COR) all DHS issued PIV credentials/identification cards and building passes that have either expired or have been collected from terminated employees. If a

PIV credential/identification card or building pass is not available to be returned, a report shall be submitted to the COR, referencing the PIV credential, pass or card number, name of individual to who it was issued and the last known location and disposition of the PIV credential, pass or any other TSA-issued cards.

f) The contract ISSO shall determine and enforce the appropriate frequency for changing passwords/PINs in accordance with appropriate guidance documentation along with the use of a second factor authentication to follow Executive Order 14028 “Improving the

Nation’s Cybersecurity” for Multi-factor Authentication (MFA). In the absence of specific guidance, where applicable, passwords shall not remain in effect longer than ninety (90) days.

D. Federal Risk and Authorization Management Program (FedRAMP):

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

a) Comply with Federal Agency cloud requirements per CCSH;

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

c) SSI, PII and SPII shall be encrypted in storage and in transit as it is dispersed across the cloud;

d) Sanitization of all TSA data shall be done as necessary at the IaaS, PaaS, or SaaS levels;

e) Cloud bursting shall not occur;

f) TSA data shall be logically separated from other cloud tenants;

g) All system administrators shall be properly cleared and vetted U.S. citizens;

h) TSA data shall not leave the United States; and

i) The cloud internet connection shall route via an approved DHS Trusted Internet

Connection (TIC) and intrusion detection system (IDS). 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 IDS 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.

D2. 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. The private sector systems are required to go through the Security

Authorization Process and the RMF in accordance the Federal Information Systems Management

Act (FISMA) and NIST SP 800-37. The cloud internet connection shall be behind a commercial

Trusted Internet Connection (TIC) that has an approved IDS deployed. Security event logs and application logs shall be sent to the TSA SOC. Incidents as defined in the TSA MD 1400.28

ISSP, and its Attachment 1 (TSA ISSP PD and TSA ODP) 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 and communicated by the COR or contract security point of contact (POC).

E. Interconnection Security Agreement (where applicable):

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

E1. Interconnections between DHS/TSA and non-DHS/TSA IT systems (i.e., Contractor Owned

Contractor Operated (COCO) systems) shall be established only through authorized contractual agreements and funding, controlled interfaces and via approved service providers. The controlled interfaces shall be accredited at the highest security level of information security on the network. Connections with other Federal agencies shall be documented using an approved

Interagency Agreements (IAA); Memoranda of Understanding/Agreement (MOU/MOA), Service Level Agreements (SLA) or Interconnection Service Agreements (ISA).

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

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

1.3 ITAR SME Cybersecurity Supply Chain Risk Management (C-SCRM)

Cybersecurity C-SCRM language is applicable for requirements for the use of supplies and services to include the following:

a. Definitions:

i. Component: a unit defined by the supplier that connects to and functions as part of the product. For software products, a component is a unit of software defined by a supplier at the time the component is built, packaged, or delivered. For hardware, a component is one hardware unit designed to connect to and function as part of a larger product.

ii.