Statement of Work (SOW)- US Canada ID Checking Guides.docx

Statement of Work (SOW) for US Canada ID Checking Guides

I. Background

In 2008, TSA acquired 2500 copies each of the US and International Checking Guides from the Driver’s License Guide Company in Redwood, CA for distribution to all TDC positions throughout the United States and its territories. The Driver License Guide Company is the publisher, copyright owner, and sole distributor of the U.S. and Canada I.D. Checking Guide, the International I.D. Checking Guide and the U.S. Identification Manual. This is the only known source of this copyrighted material. These guides are updated every year. TSA has acquired approximately 2450 copies of the US ID Checking Guide, the International Edition, and Docutector annually through 2021. It is now time to renew the order for the 2022 issue, so TDCs have continued access to current security features in IDs presented for access into sterile areas of federalized and SSP airports.

II. Requirements

One year’s access to the Docutector website database is required for all 28 CAT X and spoke airports. The same Docutector website database access will be provided to all 74 hubs and 373 spoke airports.

III. Delivery / Performance Time

Delivery required by (Supplies):

All shipments of US & Canada and International I.D. Checking Guides are to be shipped via First Class or Priority Mail. Combined shipments shall be executed to the maximum extent possible.

Period of Performance (Services): To be determined.

DHS and TSA Enterprise Architecture (February 2022):

The Contractor shall ensure that all architectural artifacts including but not limited to solutions, business, Data, IT elements for legacy Transportation Security Equipment (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, and the (The Common Approach to Federal Enterprise Architecture), the Technology Business Management (TBM) Taxonomy, and Federal Information Technology Acquisition Reform Act (FITARA).

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

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

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

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

d. TSA functional capabilities

e. TSA operational capabilities

f. TSA lines of business

g. TSA business processes

h. TSA funding sources

i. TBM Taxonomy for IT cost transparency

ii. This includes new Transportation Security Equipment (TSE) and Legacy TSE that utilizes IT software, services, or equipment including embedded IT elements such as network switches, routers, In printers, etc.

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

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

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

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

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

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

Information and Data Governance and Management 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.

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

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

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

iv. 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:

a. Data models containing entities and attributes, identifying authoritative and trusted data sources, and depicting relationship mapping and, or linkages

b. Metadata information to define data definitions

c. Detailed data formats, type, and size

d. Delineations of the referential integrity (e.g., primary key/foreign key) of data schemas, structures, and or taxonomies

e. Information exchange specifications

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

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

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

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

Cybersecurity Policy for TSA Government Acquisitions

A. General Security Requirements:

A.1. 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 4300A Sensitive Systems Policy Directive, DHS 4300B National Security Systems (NSS) PD for classified systems, TSA MD 1400.3 Information Technology Security (ITS), TSA Information Assurance (IA) Handbook & supplemental Technical Standards (TSs) and Standard Operating Procedures (SOPs).

A.2. 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.3. The Contractor shall perform periodic reviews to ensure compliance with cybersecurity, information security and privacy requirements.

A.4. 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 PD 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-53 standards.

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

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

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

A.9. 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.10. The Contractor shall make all system information and documentation produced (in support of the contract) available to TSA upon request.

B. Training Requirements:

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

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

B.3. 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 will be notified if they have a position with Significant Security Responsibilities.

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

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

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

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

C. Configuration Management (hardware/software/applications):

C.1. 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 will provide access to the DHS Information Security Performance Plan.

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

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

C.4. The acquisition of commercial-off-the-shelf (COTS) Information Assurance (IA) and IA-enabled IT products (to be used on systems entering, processing, storing, displaying, or transmitting “sensitive information”) shall be limited to those 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.

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

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

1. USGCB Guidelines:

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

2. DHS Sensitive Systems Configuration Guidance:

a. http://dhsconnect.dhs.gov/org/comp/mgmt/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.

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

C.6. The Contractor shall establish processes and procedures for continuous monitoring of Contractor systems that contain TSA data/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.

D. Risk Management Framework (RMF):

[This RMF section is not applicable if contract already addresses this clause DHS Sensitive Information Required Special Contract Terms (MARCH 2015), SAFEGUARDING OF SENSITIVE INFORMATION for contracts that have a high risk of unauthorized access to or disclosure of sensitive information. See slides for additional information]

D.1. The Security Authorization (SA) and Ongoing Authorization (OA) processes, in accordance with recent NIST SP 800-37 and SP 800-137, 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).

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

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

D.4. 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.

D.5. 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:

1) Security Assessment Report (SAR),

2) Security Plan (SP) or System Security Authorization Agreement (SSAA),

3) Contingency Plan,

4) Contingency Plan Test Results,

5) Federal Information Processing Standards (FIPS) 199 Security Categorization,

6) Privacy Threshold Analysis (PTA),

7) E-Authentication,

8) Security Assessment Plan (SAP),

9) Authorization to Operate (ATO) Letter,

10) Plan of Action and Milestones (POA&M), and

11) Ongoing Authorization Artifacts

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 Information Assurance Compliance Systems (IACS) or Tool of Record shall be completed correctly, thoroughly and in a timely manner for all steps of the RMF.

D.6. 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.

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

E. Contingency Planning:

E.1. The Contractor shall develop and maintain a Contingency Plan (CP), to include a Continuity of Operation Plan (COOP), to address circumstances whereby normal operations 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.

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

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

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

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

E.6. 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.

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

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

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

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

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

E.12. 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.

E.13. 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.

E.14. 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.

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

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

E.17. 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

E.18. 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.

F. Program Performance and Audit:

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

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

F.3. 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 PD Attachment H Plan of Action and Milestones (POA&M) Process Guide.

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

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

FedRAMP Requirements: Private sector solutions shall be hosted by a Joint Authorization Board (JAB)-approved Infrastructure as a Service (IaaS) CSP and shall follow Federal Risk and Authorization Management Program (FedRAMP) requirements. The CSP shall adhere to the following in addition to the FedRAMP requirements:

· 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 be behind a commercial 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.

G.1. 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 IACS. 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 E3A deployed. Security event logs and application logs shall be sent to the TSA SOC. Incidents as defined in the TSA Management Directive 1400.3 Information Technology Security (ITS) and its Attachment 1 (TSA IA Handbook) shall be reported to the TSA SPOC 1-800-253-8571. DHS Information Security Vulnerability Management Alerts and Bulletins shall be patched within the required time frames as dictated by DHS and communicated by the COR or contract security point of contact (POC).

H. Information Assurance Policy:

H.1. All proposed services, hardware, software, applications, etc. shall be compliant with applicable DHS 4300A Sensitive System Policy Directive, DHS 4300B NSS (for classified information), TSA MD 1400.3 ITS, TSA IA Handbook, Technical Standards (TSs) and Standard Operating Procedures (SOPs) prior to approval, implementation and operations.

H.2. The contractor solution shall follow all current versions of TSA and DHS policies, procedures, guidelines, and standards, which shall be provided by the CO.

H.3. Authorized access and use of TSA IT systems and resources shall be in accordance with the DHS and TSA information system policies.

I. Data Stored/Processed at Contractor Site:

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

J. Remote Access:

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

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

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

K. 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:

K.1. Interconnections between DHS/TSA and non-DHS/TSA IT systems shall be established only through controlled interfaces and via approved service providers. The controlled interfaces shall be accredited at the highest security level of information on the network. Connections with other Federal agencies shall be documented using an approved Interagency Agreements (IAA); Memoranda of Understanding/Agreement (MOU/MOA), Service Level Agreements (SLA) or Interconnection Service Agreements (ISA).

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

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

L. SBU Data Privacy and Protection:

This section is not applicable if contract already addresses this clause DHS Sensitive Information Required Special Contract Terms (MARCH 2015), SAFEGUARDING OF SENSITIVE INFORMATION for contracts that have a high risk of unauthorized access to or disclosure of sensitive information. See slides for additional information].

L.1. The contractor shall satisfy requirements to work with and safeguard Sensitive Security Information (SSI), Personally Identifiable Information (PII) and Sensitive Personally Identifiable Information (SPII). 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.

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

L.3. 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:

FIPS 197 (Advanced Encryption Standard (AES)) 256 algorithm (or higher) and cryptographic modules that have been validated under FIPS 140-2 (current version) National Security Agency (NSA) Type 2 or Type 1 encryption (current version) Public Key Infrastructure (PKI) (see current DHS 4300A Sensitive Systems document)

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

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

L.6. The contractor shall comply with SPII disposition requirements stated in the TSA IA Handbook, applicable Technical Standards, SOPs and TSA MD 3700.4, Handling Sensitive Personally Identifiable Information.

L.7. The Contractor shall ensure all source code is protected from unauthorized access, alterations or dissemination (see TSA IA Handbook, Technical Standard).

M. Disposition of Government Resources:

M.1 At the expiration of the contract, the contractor shall return all TSA information and IT resources provided to the contractor during the contract, and provide signed certifications that all assets containing or used to process TSA information have been sanitized in accordance with the TSA MD 1400.3 ITS, TSA IA Handbook, 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.

N. Special Considerations and Circumstances (where applicable):

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

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

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

N.4 The SPP, as submitted to the CO, and accepted by the ISSO, shall be incorporated into the contract as a compliance document. The Contractor shall comply with the accepted plan.

O. Trusted Internet Connection (TIC) Requirements for Managed Trusted Internet Protocol Service Offering (MTIPS):

O.1 MTIPS providers shall comply with the current FedRAMP TIC Overlay requirements in addition to the basic requirements outlined in the current DHS TIC Reference Architecture.

P. ISSO Support:

P.1 The contractor Program Manager shall ensure that contractor ISSO duties and responsibilities align with the TSA IAD/Governance, Risk, and Compliance (GRC) Branch mission and security responsibilities.

Q. Continuous Diagnostics and Mitigation:

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

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

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

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

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

· Hardware troubleshooting & Risk Management (RMA)

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

· Vulnerability scanning

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

Q.6 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.

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

R.1 In support of the CDM objective to protect high value assets (HVAs) and information, the Government has acquired security tools in order 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.

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

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

R.4 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.

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

R.6 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.

S. Passwords/PINs:

S.1 The contract ISSO shall determine and enforce the appropriate frequency for changing passwords/PINs in accordance with appropriate guidance documentation. In the absence of specific guidance documentation, where applicable, passwords shall not remain in effect longer than ninety (90) days.

T. Personal Identity Verification (PIV):

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

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

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

T.4 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 TSA’s facilities, networks, and information systems.

U. End-of-Life (EOL) / End-of-Service (EOS):

U.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 in order 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.

V. Maintenance:

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

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

W. Security in the Agile Development Process (where applicable):

TSA systems shall follow the below guidance when delivering system and application solutions to the agency –

· Applications shall be reviewed prior to acceptance by the Contractor

· Contractor shall implement Threat Modeling

· Developer shall deliver a defect list

· Developer shall implement Patching and Configuration Management strategies

· Developer shall use Component Analysis

· Developer shall implement build tests

· Developer shall implement Manual Code Inspection

· Developer shall implement Security Regression Tests

· Developer shall implement Pre-Deployment/Post Deployment Automated Tests

· Developer shall implement industry standard “Every-Sprint Practices”, which at a minimum consists of:

· Threat Modeling

· Use of Approved Tools

· Deprecate Unsafe Functions

· Static Analysis

· Conduction Final Security Review

·…