MBSE RFQ 70T04025Q7573N005.pdf
PDF 899 KB Posted
- Attached to
- Model Based Systems Engineering (MBSE)
- Solicitation number
- 70T04025Q7573N005
About this file
This is a Request for Quote (RFQ) issued by the Transportation Security Administration (TSA) for the procurement of Model Based Systems Engineering (MBSE) software and services. The RFQ seeks to acquire Cameo Systems Modeler, Teamwork Cloud, UPDM 2, and MagicDraw products from an authorized Dassault Systemes reseller. The contract will be a Firm Fixed Price (FFP) purchase order with a base year and three optional one-year periods, covering software licenses and support services for 12 Cameo Systems Modeler Enterprise Edition licenses, 12 UPDM 2 Plugin licenses, and a Teamwork Cloud Business Edition license.
Key submission details include a proposal deadline of 9AM ET on September 29, 2025, to be submitted via email to specified TSA contacts. The evaluation will be based on four factors: Dassault reseller confirmation, Statement of Work confirmation, active System for Award Management (SAM) registration, and price. The Government intends to award to the lowest-priced technically acceptable offer that provides a fair and reasonable price. Proposals will be evaluated on an "Acceptable/Unacceptable" basis for the first three factors, with proposals found non-compliant being excluded from further consideration. The contract is not set aside for any specific small business category.
View the file
Other files
| File | Type | Posted |
|---|---|---|
| Justification_CameoSystemsModeler_2025 - SIGNEDjzsmww1_Redacted1.pdf | ||
| RFQ70T04025Q7573N005v1 1449.pdf |
On GovTribe
Work with this file
- Download the original file
- Contacts named in this file
- Similar government files
- Ask GovTribe AI about this file
Text version
RFQ: 70T04025Q7573N005
TSA MBSE
Request for Quote
Procurement of Model Based Systems Engineering
(MBSE)
Purchase Order: TBD
Contents Part II- Continuation of SF1449
2.1 General
2.2 Contract Type
2.3 CLIN Schedule
2.4 Period of Performance
Part III- Statement of Work
3.1 : Requirement Information
3.2 : Scope
3.3 : Background
3.4 : Technical Requirements/Tasks/Outcomes
3.5 : Contingency and/or Continuity of Operations Support
3.6 : Cybersecurity Policy for TSA Government Acquisitions
3.7 : ITAR SME Cybersecurity Supply Chain Risk Management (C-SCRM)
3.8 : DHS-TSA Enterprise Architecture Compliance
3.9 : ITAR SME FedRAMP – Cloud and 'as-a-Service'
3.10 : ITAR SME Identity and Credentials Management (ICAM)
3.11 : Section 508 Requirements
Part IV- Contract Administration Information
4.1 : Contractor Performance Assessment Reporting System (CPARS)
4.2 : TSA Points of Contact
4.3 : Contracting Officer’s Representative
4.4 : Submission of Invoices
Part V- Special Contract Requirements
5.1 : Observance of Legal Holidays and Administrative Leave
5.2 : Interrelationship of Associate Contractors
5.3 Protests to the Agency
PART VI- Contract Clauses
6.1 : Approval of Contract
6.2 Option for increased Quantity- Separately Priced Line Item
6.3 : Option to Extend Services
6.4 : Option to Extend the Term of the Contract
6.5 : Commercial Computer Software License
6.6 : Availability of Funds
6.7 : Clauses Incorporated by Reference
6.8 : Contract Terms and Conditions Applicable to DHS Acquisition of Commercial Items
PART VII- List of Attachments
PART VIII- Representations, Certifications, and Other Statements of Offerors
8.1 Covered Telecommunications Equipment or Services-Representation
8.2 Offeror Evaluation – Commercial Products and Commercial Services
8.3 Offeror Representations and Certifications- Commercial Items
8.4 Certification Regarding Responsibility Matters
PART IX- Instructions, Conditions, and Notices to Offerors
9.1 : Questions and Amendments
9.2 : Errors, Omissions or Ambiguities
9.3 : Proposal Cost Payment
9.4 : Proposal Acceptance Period
9.5 : Instructions to Offerors- Commercial Items
9.6 : Proposal Preparation
9.7 : Proposal Submission Instructions
9.8 : Proposal Content
PART X- Evaluation Factors for Award
10.1 : Conformance to RFQ
10.2 : Source Selection Process
10.3 : Basis of Award
10.4 : Evaluation Factor Ratings
10.5 : Responsibility Determination
10.6 : Evaluation Approach
2.1 General
Part II- Continuation of SF1449
The purpose of this Request for Quote (RFQ) solicitation is to procure Model Based Systems Engineering (MBSE), specifically Cameo System Modeler, Teamwork Cloud, UPDM 2, and MagicDraw as specified in the below CLIN Schedule.
A Justification and Approval for Other than Full and Open Competition pursuant to FAR 6.302-1(a)(2)(ii), Only One Responsible Source/Brand Name Justification and No Other Supplies or Services Will Satisfy Agency Requirements is outlined, for reference, in Attachment A.
2.2 Contract Type
The Government contemplates award of a Firm Fixed Price (FFP) Purchase Order resulting from this solicitation.
2.3 CLIN Schedule
The below table outlines the FFP CLIN structure of this RFQ. Offerors must utilize CLIN Schedule, when submitting their Volume IV Factor 4 Price Proposal. All FFP CLINs and Optional CLINs shall include any labor and material costs in the total unit CLIN price. Offerors are encouraged to offer discounts.
Table 1: CLIN Schedule
CLIN Description QTY Price
CLIN 0001 Base Year:
Model Based Systems Engineering (MBSE) to include:
Teamwork Cloud - Business Edition 1
Cameo Systems Modeler - Enterprise Edition (Shareable) 12 UPDM 2 Plugin (Shareable) 12 MagicDraw Teamwork Server, over 10 connections 1 UPDM 2 Plugin (Shareable) Support Services 12 Cameo Systems Modeler - Enterprise Edition (Shareable) Support Services 12 Teamwork Cloud - Business Edition Support Services 1
CLIN 1001 Option Year One: Model Based Systems Engineering (MBSE) to include:
UPDM 2 Plugin (Shareable) Support Services 12
Cameo Systems Modeler - Enterprise Edition
CLIN 2001 Option Year Two: Model Based Systems Engineering (MBSE) to include:
UPDM 2 Plugin (Shareable) Support Services 12
Cameo Systems Modeler - Enterprise Edition
CLIN 3001 Option Year Three: Model Based Systems
UPDM 2 Plugin (Shareable) Support Services 12
Cameo Systems Modeler - Enterprise Edition
Engineering (MBSE) to include:
2.3.1 Option for Modified Quantities
The Government may exercise Optional CLINs 1001 - 3001 at less than or equal to the quantity called for in the Schedule at the unit price specified. The CLINs may be exercised more than once up to the maximum quantity specified per CLIN.
2.4 Period of Performance
The period of performance is a base year and three (3) option years.
Table 2: Period of Performance
Contract Year Period of Performance Base Period Twelve (12) months from delivery of licenses Option Year 1 Twelve (12) months from date of option exercise Option Year 2 Twelve (12) months from date of option exercise Option Year 3 Twelve (12) months from date of option exercise
Part III- Statement of Work
3.1 : Purpose The Transportation Security Administration (TSA) Requirements and Capabilities Analysis (RCA) is pursing the acquisition of Model-Based Systems Engineering (MBSE) software to support initiatives within RCA’s Analysis & Engineering (A&E) directorate. RCA’s primary functions include assessing current operations, conducting gap analyses, managing needs identification, and developing requirements that generate new and improved security capabilities aligned with the future vision for aviation security. The principal user of the MBSE tool in the first phase will be the Requirements Development Branch (RDB) of the Requirements, Human Performance and Engineering Division (RHPED) within RCA A&E. The objective is to expand the use of the MBSE tool throughout TSA to provide a fully integrated systems engineering environment. Cameo Systems Modeler and the associated plugins and tools have been utilized by RHPED since 2019 to be providing MBSE requirements management across numerous requirements documents.
The MBSE software is Cameo Systems Modeler (produced by Dassault Systems), a MBSE tool comprised of the following components: MagicDraw Architect, SysML Plugin, and Cameo Simulation Toolkit. Cameo Systems Modeler is currently utilized by TSA and also by numerous federal agencies including the US Department of Defense (DoD), National Aeronautics and Space Administration (NASA), Department of Energy, and large systems integrators.
At a high level, RHPED’s mission within TSA is to facilitate the development of an integrated system and oversee the development of Transportation Security Equipment (TSE) requirements, helping to define future capabilities at a system-wide level enabling an integrated, interoperable, and modularized system. As industry moves towards Model-Based Systems Engineering (MBSE) practices and methodologies, TSA will need to adopt these practices and tools to form a fully integrated system model that can be used throughout the lifecycle. The following are a number of detailed uses RHPED intends to use the MBSE software in its mission:
• Development of user level requirements for implementation of an acquisition program under DHS Acquisition Directive (AD) 102-01 and DHS Directive 107-01.
• Documenting business cases for requirements based on capability needs defined through the development of Capability Analysis Study Plans (CASPs) and Capability Analysis Reports (CARs)
• Generating and storing the following artifacts to support future acquisition program activities:
o Mission Essential Capabilities Process (MECP) o Capability Analysis Reports (CAR) o Mission Need Statements (MNS) o Operational Requirements Documents (ORD) o Consolidated Operational Requirements Documents (CORD) o Functional Requirements Documents (FRD)
• Performing full traceability between the MECP, CAR, MNS, ORD and FRD elements o Identifying requirement traceability gaps early and often o Propagating impact analysis of changes made throughout the full set of artifacts
• Configuration management of requirements, architecture, and baselines o Tracking requirement changes and justification for those changes
• Enhancing support and collaboration on requirements activities
• Defining and generating user-defined reports to enhance and support collaboration on requirements activities
• Identifying errors and traceability gaps throughout requirements, architecture and design elements
• Identifying the potential impacts requirement and architectural changes will have through multiple levels of requirements and documents
• Supporting the development, storage, traceability, and maintenance of test cases and test plans
• Generating requirements, architecture, and design documents
• Establishing traceability between requirements, architecture, and design elements
• Re-using prior acquisition program requirements and existing traceability to inform future requirements and programs
The RHPED organization proactively defines future capabilities at a system-wide level to enable an integrated, interoperable, and modularized system pursuant to their mission as identified in the Section III. MBSE end products is currently utilized for consumption by numerous stakeholders and support leadership’s decision-making processes across TSA.
3.2 : Deliverables / Special Delivery Instructions
Software, software maintenance. No special delivery instructions.
3.3 Place / Location of Performance / Delivery
The Contractor shall provide the licenses to Requirements and Capabilities Analysis at TSA Headquarters, 6595 Springfield Center Dr, Springfield VA, 22150. No travel will be required.
3.4 Contingency and/or Continuity of Operations Support
CONTINGENCY AND/OR CONTINUITY OF OPERATIONS SUPPORT OF TRANSPORTATION
SECURITY ADMINISTRATION OPERATIONS (JUNE 2024)
A. The definitions of specific contingency or emergency-related terms can be found in the National Response Framework available from the National Response Framework Resource Center glossary at http://www.fema.gov/emergency/nrf/.
B. Force and effect of this requirement. The Contractor shall provide surge capacity, reestablish functions, and reconstitute capability and performance under this contract as quickly as possible in response to an incident and/or as ordered by the Contracting Officer in order to meet the requirements necessitated by occurrences or conditions as described in any of the following clauses:
1. “Excusable Delays” paragraph of FAR 52.212-4, “Contract Terms and Conditions - Commercial Products and Commercial Services” clause
2. FAR 52.249-14, “Excusable Delays” clause
3. Related conditions as described in other clauses such as FAR 52.249-8 “Default (Fixed-Price Supply and Service)”, FAR 52.249-9 “Default (Fixed-Price Research and Development)”, or FAR 52.249-10 (Fixed-Price Construction)” when included in the contract.
C. Response functions and capabilities. The Contractor shall establish and maintain the following capabilities as a requirement of this contract.
1. Continuity of Operations (COOP) Plan. The Contractor shall establish a written continuity of operations plan in accordance with “Continuity Guidance Circular (CCG), FEMA National Continuity Programs” of February 2018. In general, COOP plans must be designed in order to:
a) Minimize loss of life, injury, and property damage.
b) Mitigate the duration, severity, or pervasiveness of disruptions that do occur.
c) Achieve the timely and orderly resumption of essential functions and the return to normal operations.
d) Protect essential facilities, equipment, records, and assets.
e) Be executable with or without warning.
f) Meet the operational requirements of the TSA. Continuity plans need to be operational within minutes of activation, depending on the essential function or service, but certainly should be operational no later than 12 hours after activation.
g) Meet the sustainment needs of the TSA. An organization may need to plan for sustained continuity operations for up to 30 days or longer, depending on resources, support relationships, and the respective continuity strategy adopted.
h) Ensure the continuous performance of essential functions and operations during an emergency, including those such as pandemic influenza that require additional considerations beyond traditional continuity planning.
http://www.fema.gov/emergency/nrf/
i) Provide an integrated and coordinated continuity framework that takes into consideration other relevant organizational, governmental, and private sector continuity plans and procedures.
2. The Contractor’s COOP Plan is intended to be executed in response to an incident, and the COOP Plan shall address each of the following requirements in depth, in addition to the essential functions described in CCG:
a) Communications. In the case of an applicable incident or a notification per paragraph (D) “Response Requirement” below, the Contractor shall maintain or be able to re-establish active, real-time communication with its employees under the contract during the 24-hour day period on all days during the week such that the Contractor can ensure performance under the contract will continue at such alternate locations under the contract to meet specified deliverables and/or response to surge capacity. Likewise, the Contractor shall ensure that effective communication about its contract performance can continue with the Contracting Officer, taking into account the operational profile or location of TSA facilities or assets in response to an incident in order to meet specified deliverables and/or response to surge capacity orders from the Contracting Officer.
b) Facilities. In the case of an applicable incident or a notification per paragraph 2(e) “Response Requirement” below, the Contractor shall be able to re-constitute contractor presence at self-provided facilities or at Government-provided facility space as may be required in order to meet specified deliverables and/or response to surge capacity orders from the Contracting Officer.
c) Information Systems/Network. In the case of an applicable incident or a notification per paragraph 2(D) “Response Requirement” below, the Contractor shall maintain and be able to re-constitute an information systems network at its facilities or for use at alternate facilities as may be necessary in order to meet specified deliverables and/or respond to surge capacity orders from the Contracting Officer.
d) Annual or Periodic COOP Exercise. Under the monitoring of the Contracting Officer and Contracting Officer’s Representative (COR), the Contractor shall conduct an annual exercise to test the capabilities of its COOP Plan, or the Contractor may be included in periodic TSA COOP exercises as a means of fulfilling this requirement. Typically, a simulated scenario for the exercise will be developed, and the contractor’s management team will place the scenario into action on a simulated basis. As with all exercises, responses to the exercise must be based on the known capacities and capabilities of the contractor’s personnel and assets and take the actual disposition and locations of personnel and assets into account at the initiation and during the conduct of the exercise. Thus, while the exercise’s scenario is simulated, the contractor’s ability to initiate and to plan the execution of a response to the scenario via the COOP Plan is actual and will be assessed by the Government. The Contractor shall implement recommendations as a consequence of the Government’s assessment of its performance in response to the exercise. The Government’s assessment of COOP plan practice may be likewise included at the Government’s discretion as a portion of the “management” element assessed under the Contractor Performance Assessment Reporting System. Initiation of an exercise in response to the requirements of this term does not entitle the Contractor to an equitable adjustment or otherwise constitute a change to this contract.
e) Surge capacity and Continuity of Operations (COOP). The Contractor may be required to provide either surge capacity and/or a COOP response to conditions related to this term.
“Surge capacity” means that the volume and pace of the contractor’s performance is required to increase to meet the TSA’s increased volume of work and tempo of operations in an emergency situation. “COOP” means that the contractor may have to conduct various activities to re-establish or reconstitute operations in response to an incident, which could also include a necessity to provide for surge capacity.
D. Response Requirement. The Contractor shall provide surge capacity to implement an increased workload within 48 hours of notification by the Contracting Officer in the event of:
1. A specific declaration of national emergency by the Executive Office of the President and/or the occurrence of an Incident of National Significance or Major Disaster;
2. A contingency operation initiated by DHS and/or the TSA;
3. A continuity of operations re-establishment of DHS and/or its components' locations, deployments, or operational profiles;
4. An emergency or event that affects DHS or TSA operations, requires a specific response as directed by the President, Secretary of Homeland Security, or Principal Federal Official so designated, and/or actuates part or all of the requirements within the National Response Framework;
5. An increase in the Threat Levels published via the Homeland Security Advisory System, either on a national or an industry/sector specific basis (especially with respect to the Threat Conditions of “High,” and/or “Severe”); and/or
6. The establishment of a specific TSA Critical Incident Management Group related to the functional area supported by this contract.
Staffing requirements may increase dramatically during such contingency operations or events. During the beginning of a contingency, the contractor shall be prepared to augment staffing for the duration of the contingency in order to not impact the timeliness of other tasks, which may also be critical during a contingency.
E. Ordering Surge Support. When the contractor’s support to provide surge capacity in response to the requirements of this term is required under the contract, a duly appointed and warranted Contracting Officer will order such support in writing. Only such a designated Contracting Officer is authorized to direct Contractor’s performance in support of the requirements of this term.
F. Annual Statement Affirming Compliance. During each year of performance while this contract is in force, the Contractor is required to submit to the Contracting Officer, on the first day of December or the next following business day, a statement affirming the contractor’s intent to comply fully with the requirements of this term and to indicate sufficient internal capacity to do so.
The Contractor shall include the terms of this special contract requirement in all subcontracts awarded under this contract.
3.6: Cybersecurity Policy for TSA Government Acquisitions
Cybersecurity Policy for TSA Government Acquisitions (July 2023)
A. General Security Requirements:
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 Policy Directive 4300A, “Information Technology System Security Program, Sensitive Systems, version 13.3, Feb 23, 2023 (hereafter known as DHS 4300A); DHS National Security Systems Policy Directive 4300B Version 10.1, November 21, 2018 for classified systems (hereafter known as DHS 4300B); TSA MD 1400.3 Information Technology Security (ITS); TSA Information Assurance (IA) Handbook; supplemental Technical Standards (TSs) and Standard Operating Procedures (SOPs); TSA Cloud Computing Security Handbook (CCSH); and the DOD Cloud Computing Security Requirements Guide (CC SRG).
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.
3. The Contractor shall perform periodic reviews to ensure compliance with cybersecurity, information security and privacy requirements. The Contractor shall comply with proper DHS and TSA security controls to ensure that the Government's security requirements are met. These controls are described in DHS 4300A, TSA MD
1400.3 ITS and the TSA Information Assurance (IA) Handbook security policy documents and are based on the current National Institute of Standards and Technology (NIST) Special Publication (SP) 800-32 Rev 2 and 800- 53 Rev 5 standards.
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).
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.
7. The Contractor shall sign a DHS Form 11000-6 Non-Disclosure Agreement (NDA) within thirty (30) calendar days of the contract start date.
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.
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.
10. The Contractor shall make all system information and documentation produced (in support of the contract) available to TSA upon request.
B. Training Requirements:
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).
2. The Contractor shall complete any TSA-related Privacy training on an annual basis.
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 shall be notified if they have a position with Significant Security Responsibilities.
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.
5. Cybersecurity and privacy training supplied by the Contractor shall meet standards established by NIST and set forth in DHS and TSA security policy.
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.
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):
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 shall provide access to the DHS Information Security Performance Plan.
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.
3. The Contractor shall ensure all sites, facilities or operational functions impacted by patching are compliant within 14 days of change approval and release.
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.
5. US Government Department of Defense/Department of Homeland Security, Security Technical Implementation Guides (STIGs)
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 DoD Security Technical Implementation Guides (STIGs) and in accordance with DHS and TSA guidance.
1. DoD STIGs/SRG:
a. https://public.cyber.mil/stigs/
2. DHS Sensitive Systems Configuration Guidance:
a. https://dhsconnect.dhs.gov/org/comp/mgmt/ocio/ciso/Pages/sscg.aspx
The standard installation, operation, maintenance, management, updates and/or patching of software shall not alter the configuration settings from the approved USGCB configuration. The information technology shall also use the Windows Installer Service for installation to the default “program files” directory and shall be able to discretely install and uninstall.
b. Applications designed for general end users shall run in the general user context without elevated system administration privileges.
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):
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).
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.
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.
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.
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),
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 Mandated tool or System of Record shall be completed correctly, thoroughly and in a timely manner for all steps of the RMF.
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.
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:
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.
2. 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.
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.
4. The Contractor shall ensure the availability of critical resources and facilitate the COOP in an emergency situation.
5. The Contractor shall test their CP annually and retain records of the annual CP testing for review during periodic audits.
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.
7. The Contractor shall ensure the CP addresses emergency response, backup operations, and recovery operations.
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.
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.
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.
11. The Contractor shall ensure all TSA data (e.g., email servers, data servers, etc.) is incrementally backed up on a daily basis.
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.
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.
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.
15. The Contractor shall ensure that data at the secondary location is current as required by the system’s availability security categorization impact rating.
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).
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.
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:
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.
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.
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 Attachment H Plan of Action and Milestones (POA&M) Process Guide.
G. Federal Risk and Authorization Management Program (FedRAMP):
G1. If a vendor is to host a system with an approved Cloud Service Provider (CSP), the CSP and shall adhere to the following:
• Comply with Federal Agency cloud requirements per CCSH;
• Identity and entitlement access management shall be done through Federated Identity;
• SSI, PII and SPII shall be encrypted in storage and in transit as it is dispersed across the cloud;
• Sanitization of all TSA data shall be done as necessary at the IaaS, PaaS or SaaS levels;
• Cloud bursting shall not occur;
• TSA data shall be logically separated from other cloud tenants;
• All system administrators shall be properly cleared and vetted U.S. citizens;
• TSA data shall not leave the United States; and
• The cloud internet connection shall route via an approved DHS Trusted Internet Connection (TIC) that has EINSTEIN 3 Accelerated (E3A) capabilities deployed. These include but are not limited to the analysis of network flow records, detecting and alerting to known or suspected cyber threats, intrusion prevention capabilities and under the direction of DHS detecting and blocking known or suspected cyber threats using indicators. The E3A capability shall use the Domain Name Server Sinkholing capability and email filtering capability allowing scans to occur destined for .gov networks with malicious attachments, Uniform Resource Locators and other forms of malware before being delivered to *.gov end-users.
G2. 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 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:
1. All proposed services, hardware, software, applications, etc. shall be compliant with applicable DHS 4300A, DHS 4300B (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.
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.
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:
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.
2. Any unauthorized Contractor employee(s) remote access connection to TSA networks shall be terminated immediately at the sole discretion of TSA.
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:
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).
2. ISAs shall be reissued every three (3) years or whenever any significant changes have been made to any of the interconnected systems.
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.
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.
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.
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)
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).
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.
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.
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:
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):
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 (or DHS 4300B for classified information).
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.
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.
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):
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:
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:
1. The Government, through a Continuous Monitoring as a Service (CMaaS) vendor, shall…
This is the start of the file's text. The full file is on GovTribe.
File details come from the government source that posted it. Updated .