PWS for TraCSS System Integration_Cloud Services Rev 5.pdf

Version 5 11/12/2024

PERFORMANCE WORK STATEMENT

FOR SYSTEM INTEGRATION AND CLOUD MANAGEMENT OF THE

TRAFFIC COORDINATION SYSTEM FOR SPACE (TraCSS)

Contents

1.0 System Integration PWS Overview 4

1.1. Purpose 4

2.0 Core System Integration Requirements 5

3.0. Agile/ DevSecOps Requirements 9

4.0. Configuration Management, Version Control, and Patch Management 11

5.0 . Model-Based System Engineering Requirements 11

6.0. TraCSS Performance Requirements 11

7.0. Data Services Requirements 12

8.0. Security Requirements 13

9.0 Monthly Reports 15

10. Other Applicable Conditions 16

11. Acronyms 16

12. References 19

Appendix A: List of TraCSS Software Tools and Technologies 20

Appendix B: Required Skill Sets 22

Appendix C Description of TraCSS Services 23

Appendix D: Performance Requirements Summary (PRS) 26

Appendix E: Deliverables 29

Figures Figure 1: Overview of TraCSS 4 Figure 2: TraCSS Architecture 6

1.0 System Integration PWS Overview

Section 1 provides background, scope and architecture for the Traffic Coordination System for Space to inform and provide additional context for the requirements in Section 2 and beyond.

1.1. Purpose

The National Oceanic and Atmospheric Administration (NOAA), Office of Space Commerce (OSC), requires a system integration and cloud management service for the Traffic Coordination System for Space (TraCSS). The TraCSS has been developed to fulfill the 2018 US National Space Council released Space Policy Directive-3 (SPD-3), which instructed OSC to develop a civil space traffic coordination system to support space safety and sustainability for space operators.

TraCSS is the Department of Commerce's enterprise solution for ingesting, archiving, processing, and disseminating Space Situational Awareness (SSA) data and products. TraCSS provides conjunction analysis and warning services to commercial satellite owner/operators and will expand its capabilities to encompass appropriate data and services for the launch and entry phases of missions. The system will store data from the Department of Defense (DOD), NOAA, commercial SSA data providers, and satellite Owner/Operators (O/O). TraCSS will operate 24 hours per day, 7 days a week. An overview of the TraCSS is shown in Figure 1.

Figure 1: Overview of TraCSS

Figure 1 illustrates the TraCSS components from left to right, including: (a) Data Sources; (b) TraCSS-SKYLINE (SSA application services); (c) TraCSS-OASIS (data repository); and (d) TraCSS-HORIZON; and (e) TraCSS User Interface (Presentation Layer). TraCSS HORIZON has two partitions. The first partition is a development and test environment which will be a second, separate, instantiation of the operating environment developed by the System Integrator, to provide an on-boarding function as new capabilities are introduced to operations. The second partition is for research, modeling and simulation for the maturation of experimental space science and safety advisory capabilities without interfering with the operational capacity.

TraCSS will be operated at an unclassified level and will not require storage of any classified data.

DoD data, with CUI handling requirements, will be ingested into the OASIS data repository. The DoD data will be processed through an ITAR rated software system and the resulting data products will not require any further special handling. The TraCSS system is hosted on a GovCloud at a FISMA HIGH level, which is procured through a separate procurement activity.

For further details on TraCSS, the architecture, development to date, and ancillary information please visit the TraCSS page on the OSC website at the following link:

https://www.space.commerce.gov/traffic-coordination-system-for-space-tracss/videos-listening-sessions-documents/. The link provides access to videos describing TraCSS as well as numerous listening sessions the program has conducted with industry and other stakeholders to elicit input on the development of the system.

The System Integrator contractor is responsible for platform (OASIS, SKYLINE, HORIZON) development and evolution, management of cloud services, implementation of cybersecurity protection including maintain the Authority to Operate (ATO), and system administration for the operational system supporting TraCSS mission execution. The System Integrator is not responsible for the execution of SSA services directly but serves as the TraCSS platform integrator to integrate third-party SSA data and services contracted by the government in support of the mission.

2.0 Core System Integration Requirements

Specifically, the System Integrator shall be responsible for the services and service layers highlighted in Figure 2. The government cloud infrastructure is procured under a separate contract.

Detailed descriptions of these services are listed in Appendix C. The skill sets required to satisfy these requirements are listed in Appendix B.

The System Integrator is not responsible for the direct execution of the TraCSS mission but supports the mission operations team as a system administrator to ensure that the OASIS, SKYLINE and HORIZON components remain functional.

Figure 2 indicates that the System Integrator contractor is responsible for integrating, managing, maintaining, operating, and evolving the TraCSS infrastructure, which includes:

● Automated workflow execution of the TraCSS mission and delivery of TraCSS products and services which include the automated workflows for ensuring that other third-party software, including the presentation layer service.

● Enterprise Cloud Governance.

● All system APIs

● Developing and maintaining all of the services in Figure 2 assigned to the SI.

There are multiple instances of the system deployed including, for example, the DevTest environment and depending on the computational requirements, multiple instances of the operational environment. The contractor will be provided access to all existing TraCSS code and software and access to the OSC government cloud as GFE. This includes the cloud provisioning, https://www.space.commerce.gov/traffic-coordination-system-for-space-tracss/videos-listening-sessions-documents/ https://www.space.commerce.gov/traffic-coordination-system-for-space-tracss/videos-listening-sessions-documents/

TraCSS data repository and APIs, HORIZON DevTest environment, workflows and software infrastructure, and if developed at the time of contract award, the HORIZON RM&S environment with accompanying documentation. The software tools and technologies utilized by TraCSS are listed in Appendix A.

Figure 2: TraCSS architecture

2.1. The Contractor shall maintain, administer, and evolve the following computational environments and manage the cloud services provided by the Cloud Infrastructure Service Provider selected by the Government:

2.1.1 TraCSS-HORIZON: The TraCSS-HORIZON has two main partitions: (1) the TraCSS- HORIZON research, modeling, and simulation environment (RM&S); and (2) the TraCSS- HORIZON development and testing (DevTest) environment.

2.1.1.1 The TraCSS-HORIZON RM&S environment shall:

● Run and support an instantiation of OASIS that is separate and distinct from the operational system to avoid cross-polluting the operational environment with activities that are executed the RM&S environment

● Create and execute workflows for research, testing and simulation purposes

● Receive and integrate third-party software and services

2.1.1.2 The TraCSS-HORIZON DevTest environment shall:

● Receive, test, and integrate the presentation services and the SSA application services provided by the third-party vendors contractors selected by the Government.

● Receive, test, and integrate the third party SSA services from the research environment.

● Receive, test, and integrate the software components that have been selected or developed by the System Integrator Contractor itself to provide TraCSS’s Data Policy/Rule Engine, Data Services, Enterprise Cloud Governance, and Software Services.

● Develop and test the automated workflows for invoking, and executing the TraCSS services needed to support the basic safety cycle, such as ephemeris generation and conjunction screening. Host all presentation services, SSA application services, and SIP services.

● Enable end-to-end collaboration between the Contractor and other TraCSS commercial contractors on the development, testing, installation, integration, demonstration, documentation, and delivery of TraCSS capabilities through periodic software capability builds, sprints, or releases.

● Verify that the new software and data sources function correctly and do not introduce errors.

● Enable controlled deployment.

● Enable controlled rollback if errors are inadvertently introduced into operations.

2.1.2 TraCSS SKYLINE is the computational environment where the Contractor will deploy operational versions of TraCSS services and workflows to generate data (for example CDMs) used by TraCSS customers, including U.S. government organizations, commercial satellite owners and operators (O/O), academic institutions, and members of the general public.

2.1.3 TraCSS OASIS: Data repository where SSA data feeds can be easily and consistently managed and made available to TraCSS services. TraCSS data supporting TraCSS- HORIZON test and development environment and TraCSS-SKYLINE are partitioned with separate access controls and retention policies.

2.1.4 The Contractor shall ensure that the TraCSS-HORIZON DevTest environment and the TraCSS operational environment use two different instances of the system (OASIS, SKYLINE). The TraCSS HORIZON Research, Modeling and Simulation environment shall be separate and distinct from the TraCSS HORIZON DevTest environment.

2.2 The Contractor shall manage infrastructure services that will enable TraCSS to:

● Be highly available, reliable, durable, and capable of operating despite failure of portions of the infrastructure.

● Be scalable and capable of providing secure access to globally dispersed users, SSA data producers, and SSA data consumers.

2.3 The Contractor shall follow an Agile approach to plan, design, test, develop, manage, maintain, administer, and evolve TraCSS. Specifically, relevant plans, documents, tests and code shall be updated consistently during the sprint and delivered at the end of each program increment.

2.4 The Contractor shall ensure that TraCSS operates as intended through continuous monitoring, testing, validation, interface management, and verification in support of 24/7 operations.

2.5 The Contractor shall maintain, evolve and execute a TraCSS resiliency plan to prescribe the service level objectives (SLOs) for performance, resource scalability, redundancy, reliability, continuity of operations, and cost underlying the operation of TraCSS’s Infrastructure Services.

2.5.1 Fault Recovery: The Contractor shall perform fault recovery, including managing and scaling computational resources in real time to ensure continuity of 24/7 operations.

2.5.2. System Availability: The TraCSS shall have high availability with full operational capability better than 99.95% of the time (i.e., 4.38 hours of unscheduled downtime per year).

System availability does not apply to scheduled maintenance which should be implemented in such a way as to not interfere with TraCSS operations and delivery of safety products to TraCSS users.

2.5.3. Frequency of Screening: TraCSS shall perform ephemeris generation and conjunction analysis screening every four hours or less, within a certain time frame that is defined by the HAC download to the CDM production and availability.

2.5.4. Continuity of Operations (COOP): The Contractor shall maintain and evolve, as necessary, conduct a failure modes and effects analysis and develop plans and processes to keep TraCSS operational in the event of major system failures, including regional power outages. Any changes to the plans and processes shall be submitted to the government for approval before implementation. The Contractor shall keep the Government informed about: (1) the operational status of all the TraCSS services, (2) any ongoing activities to resolve infrastructure service operational issues and restore the operational status of the TraCSS system and any backups.

2.5.5. Mean Time To Recovery: The Contractor shall ensure that mean time to recovery from a system failure is one hour, with one standard deviation of 20 minutes.

2.6 The Contractor shall maintain, evolve and manage the continuous integration / continuous delivery (CI/CD) pipeline in the HORIZON Dev/Test environment for software updates to TraCSS services and manage the testing and vetting of new applications transitioning from HORIZON to the operational system.

2.7 The Contractor shall perform system administration for the TraCSS production environment, both partitions of HORIZON and any other instantiation of TraCSS on the OSC government cloud infrastructure to ensure 24/7 TraCSS operations.

2.8 The Contractor and its subcontractors shall NOT develop Conjunction Analysis and Application Services (except Data Policy/Rule Engine and Data Migration/Archiving Policy) or provide SSA data (including raw observations and ephemerides) for TraCSS.

2.9 The Contractor shall support and enable the oversight activities of the Government and its FFRDC Team and grant full access to documentation, code, and other work products only to personnel authorized by the Government

2.10 In the event of contract termination, the Contractor shall provide education and training to their successor.

2.11 Data Rights: The TraCSS infrastructure including any code (including configuration files), architectural models, documentation or other artifacts developed by the Contractor under this contract shall belong to the Government.

2.12 The contractor shall develop, maintain, evolve, and implement TraCSS’s internal application programming interfaces (APIs), including APIs to support service interactions within and across TraCSS service layers and the REST APIs and message publication for external users.

2.13 The contractor shall deliver a complete set of documentation 90 days before the end of the contract period, to include a User Manual (for TraCSS system operators), System Manager's Manual (for TraCSS system integrator/maintainer), and API documentation that is up-to-date and current.

2.14. The Contractor shall utilize free, open-source software. If that solution is not possible, the Contractor shall develop a plan to use commercial-off-the shelf (COTS) products and seek government approval for it. If none of the previous approaches are feasible, the Contractor shall develop a plan for creating new software and seek government approval for it. In all of these cases, any code (including configuration files) developed by the Contractor shall belong to the Government.

2.15. TraCSS shall support deployment to a different cloud service provider, if required, to the greatest extent practicable in a six-month timeframe.

2.16. The Contractor shall ensure that TraCSS’s Gateway Business Logic Service is the sole entry point for Presentation Services to access other TraCSS services.

2.17. The Contractor shall ensure that individual methods in code and individual blocks of configuration files are documented in the header using comments that permit the use of documentation-generation tools.

2.18. The Contractor shall work with the Presentation Layer vendor and other vendors to resolve usability and performance issues that are uncovered during user testing and operations.

2.19 The Contractor shall ensure, working with appropriate SSA subject matter experts, that the output of TraCSS is numerically correct for the given inputs.

3.0. Agile/ DevSecOps Requirements

3.1. The Contractor shall use Agile/DevSecOps principles to provide TraCSS service operation, maintenance, evolution and continual enhancement activities, such as (but not limited to):

● Patching TraCSS services and operating system as appropriate.

● Fixing production defects.

● Streamlining and integrating security practices within the CI/CD delivery pipeline.

● Fixing cybersecurity vulnerabilities.

● Protecting and sustaining TraCSS services and data on the cloud.

● Version-controlled coding environments that lets multiple developers work on the same code base.

● Integrate with CI/CD, testing and security tools, so that when code is committed to the repository it can automatically move to the next step.

3.2. The Contractor shall increase continuous integration and continuous delivery capability by progressively layering more sophisticated automation components into the continuous integration/continuous delivery pipeline while also reducing the time to move approved TraCSS services from development to operations.

3.3. The Contractor shall provide agile metrics and data (in an electronic dashboard or Confluence or Contractor format) at the end of each sprint:

● Sprint backlog: Epics and stories for near-term implementation.

● Product backlog: This prioritized list of product features and bug fixes written in the user story format.

● Velocity and/or Burn-down chart: Once there have been enough sprints to develop sufficient experience, the product team shall project the amount of work remaining in the product backlog and estimate delivery time. Alternatively, the Contractor may report velocity.

● Burn-up chart: Once there have been enough sprints to develop sufficient experience, the product team shall forecast approximately when certain functionality may be delivered or track completed work to total work.

● Percent of accepted/rejected stories: Stories accepted or rejected by Product Owner based on acceptance criteria.

● Delivered functionality.

● Project risks: A list of conditions that could affect intended project outcomes; the team shall actively work to reduce risks to minimize their impact on the project.

3.4. The Contractor shall deliver a working capability within the timebox allotted. The definition of done for each capability will be decided by the government or its representatives in collaboration with the System Integrator.

3.5. The Contractor shall provide the following data (in an electronic dashboard such as Confluence or Contractor format) at end of each release cycle:

● System diagrams in MBSE tool: Any modifications to major architecture functions in ASOT. The government or its representatives will define "major architecture functions" in collaboration with the System Integrator.

● Delivered functionality

● % stories completed

● % accepted/rejected stories

● Escape defect rates: defects/bugs identified from previous release

3.6. The Contractor shall utilize a product to track incidents, change requests, and the continuous integration and continuous deployment (CI/CD) of TraCSS services.

3.7. The Contractor shall support development and execution of strategies for frequent and continuous building, testing, integration, and deployment of TraCSS services, utilizing automation, whenever possible, to provision, configure, and modify services across the service deployment lifecycle phases (development, integration, release, delivery, deployment, operation).

3.8. The Contractor shall perform, at a minimum, key types of tests to provide for the continuous integration of TraCSS services, including unit tests, integration tests, load tests, and acceptance tests.

3.9 The Contractor shall establish a repeatable hardening process for the download and hardening of containers for both open-source products and commercial products using DevSecOps tool capabilities such as those provided by Jenkins files and GitLab runners.

3.10. The Contractor shall use change control management solutions.

3.11. The Contractor shall maintain, evolve and execute a software factory for TraCSS for internal and external integration, including service development processes, cybersecurity activities, and continuous/automation-driven development and delivery that will be performed as part of the DevSecOps and CI/CD processes.

4.0. Configuration Management, Version Control, and Patch Management

4.1. The Contractor shall employ automated configuration management tools that: (a) enforce controls for TraCSS service development and integration; and (b) prevent unauthorized modifications to TraCSS services within and across the TraCSS Environments.

4.2. The Contractor shall apply, test, and validate the appropriate software updates for TraCSS services before promoting the services to operations.

4.3. The Contractor shall verify non-degradation testing at the conclusion of software updates for TraCSS services that are in operations.

5.0 . Model-Based System Engineering Requirements

5.1. The Contractor shall use a tool to maintain the architecture that reflects the current state of the operational system.

5.2. The Contractor shall provide the Government and its FFRDC Team with electronic access to the TraCSS MBSE tool.

6.0. TraCSS Performance Requirements

The Contractor shall ensure that the integrated TraCSS services satisfy the following performance requirements. Key Performance Parameters (KPPs) shall include, but are not limited to, the numerical values listed below:

6.1. Catalog Size: The TraCSS shall process a catalog of up to 100,000 objects. TraCSS shall be implemented as a scalable system with the ability to process a catalog of up to 200,000 objects.

6.2. Latency for Ephemeris Generation and Conjunction Analysis Screening: The TraCSS shall generate 7 to 10-day ephemerides and perform many (all active payloads) vs. all (all resident space objects) conjunction screening for the entire catalog in 1 hour or less.

6.3. Data Storage and Retrieval: The TraCSS shall store and retrieve all types of data needed for operations, development/test, and research.

6.4. Data Storage Size: The data storage size shall be unlimited.

6.5. Data Storage Replication: The TraCSS storage shall have a replication factor of at least three, or two if data is replicated across multiple regions of the government cloud.

6.6. Data Storage Replication Integrity: The TraCSS storage replication shall be implemented such that there will be no loss of data from a single server or disk failure.

7.0. Data Services Requirements

The Contractor shall ensure that the integrated TraCSS services satisfy the following Data Services requirements:

7.1. Metadata Database: The TraCSS shall track all inputs/outputs and results from all TraCSS services, including, but not limited to, ephemeris generation, conjunction screening, detailed conjunction analysis, etc.

7.2. Prevent Data Updates: The TraCSS shall allow data creation and reads; deletes (with restrictive permissions); prevent data updates; and enable data redactions while preserving the originals.

7.3. Files and File Type Standards: TraCSS shall ingest and produce data files that conform to the appropriate standard format for CCSDS OCM ephemeris, CDMs, TLEs, B3 format observations, and CCSDS Tracking Data Messages (observations). Other data and file types may be identified as TraCSS services evolve.

7.4. Data Exposed: TraCSS shall ingest and produce data via APIs or message queue that conform to the appropriate data standard.

7.5. Fine-Grained Access Control: TraCSS shall support Role-Based Access Control (RBAC) and Attribute-Based Access Control (ABAC) for TraCSS resources.

7.6. Data Storage Optimization: TraCSS shall optimize storage based on expected workloads to minimize storage costs so that: (a) it favors technologies that can use object storage, and reserve block storage for operating system files, caches, and metadata; and (b) it prefers lower-cost storage environments for data-intensive workloads.

7.7. Standard Use Cases: TraCSS shall support the various mechanisms for data access, including request-response, publish-subscribe, and bulk delivery.

7.8. Batch Data Ingest: TraCSS shall ingest large amounts of data from batches of different types of files (e.g.,, VCMs, CCSDS OCM ephemeris, CDMs, TLEs, B3 format observations, and CCSDS Tracking Data Messages (observations) and ensure that the ingested batch data conform to the appropriate standard format.

7.9. Near Real-Time Data Ingest: TraCSS shall ingest real-time data from external sources (i.e., DOD, commercial satellite owner/operators, and commercial SSA providers) and ensure that the ingested data conform to the appropriate standard format.

7.10. Data Ingest Validation: TraCSS shall perform validation within Data Ingest Service on all external data, to include, but may not be limited to as TraCSS services and data ingest requirements evolve:

● Input Ephemeris Validation: TraCSS shall perform automated validations of ephemeris files provided by external commercial providers to ensure, for example:

o Provider's digital signature.

o Ephemeris conforms to OCM file format.

● Input DOD Data Validation: TraCSS shall perform automated validations of data provided by DOD to ensure the data being supplied conforms to what is expected and there are no anomalies.

7.11. Data Types: TraCSS shall support diverse data sets, including files, structured data (relational database), documents, and graphs

7.12. Data Discovery: TraCSS shall support mechanisms for human users and machines to discover data and services, including the FAIR principles for data findability, accessibility, interoperability, and reusability.

7.13. Data Abstraction: TraCSS shall ensure that data create, read and delete functions are abstracted from the underlying data storage mechanism, whether object store, file system, database or other mechanisms.

7.14. Data Provenance: TraCSS shall ensure that all derived and output data products can be traced back to input data.

8.0. Security Requirements

8.1. The Contractor shall use a government furnished identity and access management tool (OKTA) to support authentication of entities and access controls for TraCSS.

8.2 The Contractor shall maintain and evolve TraCSS using the government security elements (FedRAMP, FISMA, Risk Management Framework) of DevSecOps, as applied to code repository management, configuration management, branching/merging code, building automation, test code coverage, and automated scanning tools.

8.3. The Contractor shall use: correlated and centralized logs; zero trust model; continuous monitoring; signature-based continuous scanning using Common Vulnerabilities and Exposures (CVEs); and runtime behavior analysis.

8.4. The Contractor shall provide the capability of auditing and logging all user access to TraCSS infrastructure services.

8.5. The Contractor shall encrypt each communication into and out of TraCSS government cloud, public cloud, or on-premises data centers (Encryption of Data in Transit).

8.6. The Contractor shall encrypt each communication and data within the TraCSS government cloud, public cloud, or on-premises data centers (Encryption of Data at Rest).

8.7. The Contractor shall utilize an encryption algorithm that is compliant with the Federal Information Processing Standards (FIPS) 140-3.

8.8. The Contractor shall collect log data from all TraCSS infrastructure services and use cyber analysis of the log data to detect and mitigate vulnerabilities, intrusion, and resource misuse.

8.9. The Contractor shall perform software vulnerability detection and act upon the results of using automated static and dynamic testing, vulnerability scanning, virus scanning, external penetration testing, and fuzz testing on incoming third-party services and source code cybersecurity scans and reports provided by third-party application providers.

8.10. The Contractor shall provide daily monitoring setup with a cloud access security broker (CASB), and continuous vulnerability scanning and management.

8.11. The Contractor shall deliver to the Government the results and describe the actions taken from the cybersecurity vulnerability testing.

8.12. The Contractor shall stand up, within the TraCSS Service Environments, versions of the system whose services use security features including:

● The Open Container Initiative (OCI) compliant and Cloud Native Computing Foundation (CNCF) certified Kubernetes platform to enable interoperability from one Kubernetes installation to the next and allow flexibility to choose between contractors if needed.

● Hardened containers to maintain security.

● The DISA Container Platform Security Requirements Guide for hardening containers.

● A Centralized Artifact Repository to hold the hardened VM images and hardened OCI compliant container images of DevSecOps software components, container security tools, and common programming platform components (e.g., COTS or free and open-source products) that can be utilized as a baseline to facilitate the authorization process.

● A Sidecar Container Security Stack (SCSS) which is enabled by DevSecOps and the container-based Kubernetes in runtime to support various capabilities, including:

correlated and centralized logs; container security; east/west traffic management; zero trust model; Role-Based Access Control (RBAC) and/or Attribute-Based Access Control (ABAC); continuous monitoring; signature-based continuous scanning using Common Vulnerabilities and Exposures (CVEs); runtime behavior analysis; and container policy enforcement.

● Security-oriented infrastructure containers and processes to do the equivalent of patching and vulnerability scanning. This means that: (1) when the containers are initially created, they are scanned prior to going into the Centralized Artifact Repository for use; and (2) there will not be any patching of the containers directly; instead, their infrastructure as code will be updated or run to include required patches, scanned, and then put into the Centralized Artifact Repository.

● IPV6 addresses in the environments.

8.13. The Contractor shall maintain and evolve as necessary a secure unclassified TraCSS integration and test pipeline between the HORIZON DevTest and the SKYLINE operational system.

8.14. The Contractor shall monitor and manage controlled secure (but unclassified) interfaces between TraCSS and person and non-person entities consisting of SSA stakeholders and data sources identified in Figure 1, including:

● Commercial SSA data providers

● Satellite owner/operators (commercial, civil, academia, international)

● Other stakeholders

● TraCSS operations sites and backup sites (co-located with NOAA operations)

● Data sources o DOD high-accuracy catalog (from 18th Space Defense Squadron) Note: the data is CUI and will be deposited on a GovCloud o Commercial sensors o Commercial satellite ephemerides and maneuver plans o Environmental data sources o International data sources

8.15. The Contractor shall ensure that TraCSS maintains its Authority to Operate (ATO) through automated security scanning and compliance with Risk Management Framework (RMF) protocols and Federal Risk and Authorization Management Program (FedRAMP) high-impact system requirements.

8.16. TraCSS OASIS ingests CUI data from the DoD in support of conjunction analysis. The CUI data has been downloaded and scrubbed via an approved DoD process. Nonetheless there is always the possibility of an inadvertent data spill. Consequently, the Contractor shall protect against an inadvertent classified data spill from DOD sources as follows:

● Work with the government team and DOD classification authority to maintain and evolve, as necessary, plan to prevent, isolate and recover from a classified data spill.

● Obtain government approval for any changes to this plan.

● Work with the government team, Cloud Infrastructure Service Provider, and DOD partners to implement this plan.

9.0 Monthly Reports

The Contractor shall provide a monthly report with the invoice via email to the COR which documents the previous month's activities. The Contractor shall provide the report to the Contracting Officer (CO) within 48 hours upon request. This report shall be prepared on a monthly basis and submitted within ten (10) calendar days after the close of each month. Each report shall contain the following:

● Hours expended during the reporting period for each contractor position filled.

● Level of funds against the ceiling of the current performance period

● A description of any problem encountered or anticipated that will affect the completion of any work within the time set, together with recommended solutions to such problems; or, a statement that no problems were encountered.

10. Other Applicable Conditions

10.1 Travel

Contractor travel may be required to support this requirement. All travel required by the Government outside the local commuting area(s) will be reimbursed to the Contractor in accordance with the Federal Travel Regulations. The Contractor shall obtain COR approval for any travel that exceeds GSA per diem rates or U.S. State Department rates in the case of foreign travel.

The Contractor shall be responsible for coordination of travel in support of Government requirements. The Contractor shall be required to invoice in accordance with FAR 31.205-46, Travel Costs, and Federal Travel Regulations (FTR), and must submit documentation and receipts of all travel costs. Only the contractor’s actual direct costs proposed in accordance with the terms of this contract associated with Non-Local Travel shall be reimbursed; no profit or prime contractor fee shall be added. Non-Local Travel is defined as travel that is more than 50 miles (using the quickest route on Google maps) from the contractor’s regular Primary Place of Performance (the place where they incur/perform 80% of their hours worked under this contract).

The contractor shall not be reimbursed for any “Local Travel.” Local Travel defined as travel within 50 miles (using Google Maps driving directions) of the contractor personnel’s primary place of performance where they perform the majority of their hours under the contract.

10.2 Other Direct Costs

Any other direct costs (ODCs) which are properly allocable to the contract shall be allowed provided such other costs are reasonable. Any ODCs, excluding travel costs, shall be pre-approved by the COR and only be considered allowable, if approved prior to the Contractor incurring these costs

11. Acronyms 18SDS: 18th Space Defense Squadron 19SDS: 19th Space Defense Squadron; a backup to 18SDS.

ABAC: Attribute-Based Access Control.

ASOT: Authoritative Source of Truth.

ATO: Authority to Operate.

API: Application Programming Interface.

CA: Conjunction Assessment.

CARA: Conjunction Assessment Risk Analysis.

CASB: Cloud Access Security Broker.

CCSDS: Consultative Committee for Space Data Systems.

CDM: Conjunction Data Message.

COLA: Collision Avoidance.

CI/CD: Continuous Integration / Continuous Delivery.

CNCF: Cloud Native Computing Foundation.

COTS: Commercial-off-the Shelf.

CVEs: Common Vulnerabilities and Exposures.

DISA: Defense Information Systems Agency.

DE: Digital Engineering.

DevTest: Development and Testing.

DevSecOps: Development, Security, Operations.

DNG: DOORS Next Generation.

DOC: Department of Commerce.

DOD: Department of Defense.

FAIR: Findable, accessible, interoperable, reusable.

FFRDC: Federally Funded Research and Development Center.

IaaS: Infrastructure as a Service.

IaC: Infrastructure as Code.

IPV6: Internet Protocol Version 6.

LCOLA: Launch Collision Avoidance.

LOST: Line of Site.

LTS: Long-Term Sustainability.

MBSE: Model-Based System Engineering.

NAPA: National Academy of Public Administration.

NASA: National Aeronautics and Space Administration.

NESDIS: National Environmental Satellite, Data, and Information Service.

NOAA: National Oceanic and Atmospheric Administration.

N-Wave NOAA Enterprise Network Program OADR: Open Architecture Data Repository.

https://nwave.noaa.gov/ https://nwave.noaa.gov/

OCI: Open Container Initiative.

OD: Orbit Determination.

OEM: Orbit Ephemeris Message.

O/O: Owner/Operator.

OPM: Orbit Parameter Message.

OSC: Office of Space Commerce.

PaaS: Platform as a Service.

PasC: Policy as Code.

Pc: Probability of collision.

PWS: Project Work Statement.

RBAC: Role-Based Access Control.

REST: Representational State Transfer.

RFP: Request for Proposals.

RMF: Risk Management Framework.

RSO: Resident Space Object SaaS: Software as a Service.

SCSS: Sidecar Container Security Stack.

SDA: Space Domain Awareness.

SDS: Space Defense Squadron.

SEP: Space Environment Preservation.

SIP: System Integration Platform.

SLO: Service Level Objective.

SPD: Space Policy Directive.

SSA: Space Situational Awareness.

SSN: Space Surveillance Network.

SST: Space Surveillance and Tracking.

STC: Space Traffic Coordination.

STM: Space Traffic Management.

SysML: Systems Modeling Language.

TCA: Time of Closest Approach.

TLE: Two-Line Element.

TraCSS: Traffic Coordination System for Space.

TraCSS-HORIZON: Research and DevTest environments.

TraCSS-OASIS: TraCSS Data Lake.

TraCSS-SKYLINE: TraCSS Operations Environment with SSA application services.

TraCSS SIP: TraCSS System Integration Platform.

UAF: Unified Architecture Framework.

UML: Unified Modeling Language.

VCM: Vector Covariance Message.

VM: Virtual Machine.

12. References

Space Policy Directive – 3, 2018

Aerospace OTR 2022-01112, Maneuvering into the Future: Open-Architecture Data Repository (OADR) Prototype: Towards Civil and Commercial Space Traffic Coordination.

Aerospace OTR 2022-00578, Statement of Dr. Matthew Hejduk to the Subcommittee on Space and Aeronautics, Committee on Science, Space, and Technology, U.S. House of Representatives.

DISA Container Platform Security Requirements Guide, 2022.

DoD Data Strategy, 2020.

George, Eric and Harvey, Seth, A Comparison of Satellite Conjunction Analysis Screening Tools, Advanced Maui Optical and Space Surveillance Technologies Conference, 12-16 Sep 2011, Wailea, Maui, HI.

Statement of Dr. Mariel Borowitz to the Subcommittee on Space and Aeronautics, Committee on Science, Space, and Technology, U.S. House of Representatives, April 29, 2022.

NASA Spacecraft Conjunction Assessment and Collision Avoidance Best Practices Handbook, December 2020.

National Oceanic and Atmospheric Administration (NOAA) Space Object Commercial Data Request for Information (RFI), Notice ID NOAA-22-SOCD-OSC, February 16, 2022.

National Oceanic and Atmospheric Administration (NOAA) Cloud Platform Management Services Request for Information (RFI), Notice ID NOAA-22-CPMS-OSC, July 19, 2022.

National Oceanic and Atmospheric Administration (NOAA) Enhanced Safety Services Request for Information (RFI), Notice ID NOAA-22-OADRESS-OSC, August 16, 2022.

Appendix A: List of TraCSS Software Tools and Technologies

Gitlab DITA Open Toolkit CoreDNS (EKS Cluster Plugin)

Zscaler Promtail Amazon EFS CSI Driver (EKS Cluster Plugin)

Crowdstrike Argo Workflows Amazon CloudWatch Observability (EKS Cluster Plugin)

Grafana Loki Tempo AWS - EC2 (Operating System) - AWS Linux

Python Mimir AWS - Karpenter

Service Now Ticketing System/CM Junit AWS - RDS (PostgreSQL)

Tenable Vulnerability Manager

- FedRAMP (Tenable .io) Robot Framework AWS - EC2 Bastion Host

Maven Postman AWS - EC2 Windows-vpn radius

Jenkins REST-assured AWS - Simple Notification Service (SNS)

Okta: (MFA) Nginx AWS - CloudWatch

Docker & Docker Desktop Apache HTTPd AWS - AWS Backup

Containerd Apache Nifi AWS - Directory Service

Kubernetes Apache Kafka AWS - Elastic File System (EFS)

ArgoCD MongoDB AWS - Support

Coralogix PostgreSQL AWS - VPC (Virtual Private Cloud)

Trivy Dbeaver AWS - AWS GovCloud

Jira Service Management NoSQLBOOSTER AWS - Subnets

GIT Repository AppGate AWS - Route Tables

Bazel Palo Alto (Prisma) AWS - Internet Gateways

SpringBoot F5 AWS - Egress-Only Internet Gateways

Java 21 Cyberark OAuth2 Proxy AWS - DHCP Option Sets

Checkstyle Keycloak AWS - Elastic IPs

Helm SQL/Map/NoSQLMAP AWS - Endpoints

Kubectl Apache JMeter AWS - Instance Connect Endpoints

Kubernetes Cameo Systems Modeler AWS - CodeCommit (Git repo) fluxcd Atlassian JIRA Premium AWS - AWS AppConfig

Puppet Advanced Roadmaps AWS - IAM (Identity and Access Management)

SonarQube (SonarQube Server) Git AWS - S3 (Simple Storage Service)

Jira Confluence Doxygen AWS - CloudTrail

Ansible Grafana Agent AWS - Config

Terraform Grafana AWS - Key Management Service (KMS)

Istio Loki AWS - API Gateway

Visual Studio Code Sonatype Nexus AWS - CloudFormation

Github Slack AWS - Control Tower

Eclipse Harbor AWS - Route 53

IntelliJ IDEA Palo Alto Prisma AWS - Web Application Firewall

Prometheus Splunk Cloud Platform AWS Shield

Anchore AWS - EKS Axonius

Portswigger (BurpSuite) AWS - ECR Devo

Zabbix Amazon EBS CSI Driver (EKS Cluster Plugin) Elastic

GitLeaks CSI Snapshot Controller (EKS Cluster Plugin) Software AG oXygen XML Kube-proxy (EKS Cluster Plugin) Ivanti

Qualys

Appendix B: Required Skill Sets

The proposed personnel and staffing plan should include the following preferred skill sets:

TraCSS SI Project Manager/IT Engineer Chief (Key Personnel): Knowledge in applications of agile development, including Scrum methodology and skilled developing processes that support continued delivery and continued improvement of products. Can apply and use metrics appropriate to agile development to projects and tasks to support customer. Demonstrated skills in leading technical teams.

Lead Engineer/Scrum Master/Software Engineer V (Key Personnel): Knowledge and experience of agile development scrum methodology including how to manage and motivate team members. Able to collaborate with product manager to determine goals and priorities for spring planning, grooming and product release. Manage teams to achieve mature sprints with on-time delivery and appropriate documentation and reporting. Current knowledge of software tools and techniques.

Lead SSA Domain Engineer/Software Engineer V (Key Personnel): Knowledge and experience in the space situational awareness domain. Understands various standard, types and formats of data related to satellite ephemerides and meta-data and processes around orbital determination. Understands astrodynamics, conjunction analysis and risk assessment, trajectory planning and optimization and familiar with the operational environment.

Appendix C Description of TraCSS Services

Model Element Element Description

API Gateway This service is the gateway for all APIs engaging with the system.

Message Publication This service pushes notices and alerts to users, such as CDMs, via email, text or other media (Responsibility of the System Integrator Contractor).

Data Products Operations GUI Owner/Operator GUI Public GUI

These services are the responsibility of the Presentation Layer vendor.

Monitor Service This service waits for a message indicating the arrival of a new TraCSS data packages. It then

Cleanup Service This service removes files in the volume mount shared between the Cleanup Service, Monitor Service, Ephemeris Generation Service, and CA Screening Service when the files are no longer needed. When an application flag is set, this service also persists ephemerides in Long- Term Storage for verification purposes.

Ephemeris Generation Service (NOTE: This service might be supplemented with a third-party SSA vendor in the future)

This service takes an initial state vector and covariance and propagates the orbit to generate an ephemeris that predicts the position of the object in the future. It is important that orbit determination and ephemeris generation use a consistent set of orbit models for high accuracy.

Conjunction Analysis Screening Service (NOTE: This service will be supplied by a third-party SSA vendor in the future)

This service performs conjunction analysis screening by comparing ephemerides of objects in the catalogue and identifying points in time where probability of collision between two objects is above a specified threshold. For each potential conjunction, the service generates a Conjunction Data Message (CDM).

Risk Assessment Support, CA Mitigation Planning Data Quality and Actionability Monitoring, Orbit Determination and Fusion, Federated Catalog Reconciliation, SSA Data and Information

These services will be supplied by third-party tools and SSA vendors.

Policy/Rules Engine This service contains business logic that manages data access controls and context-aware data security policies for internal and external TraCSS users

Subscriber Service A messaging service where the senders of messages are decoupled from the receivers of messages.

Publishers (sources of data) push messages out to any number of subscribers (receivers of data) that have subscribed to their topics. This service listens on Message Broker topics and allows subscribers to retrieve those messages as well. The Subscriber Service exposes its REST API to external TraCSS users.

Ingest and Post Service This service ingests and initiates the storage of Space- Track data and prepares the data for processing by other services. This service also posts data to Space-Track after processing is complete.

Ingest Validation Service This service unpacks and validates external data DoD data that TraCSS receives and sends that data to storage.

Provenance Service This service persists logs from the Software and Data Services to Relational Storage, captures event timelines for metrics, and sends logs to the Internal User Interface or other visualization service. The Provenance Service exposes its REST API to external TraCSS users.

Metadata Service This service takes parsed data and initiates storage in Relational Storage. This service exposes a REST API to external TraCSS users so that users can retrieve information such as CDMs, ELSETs, State Vectors, and OCMs

Message Broker This service allows producers to send messages to consumers on specific topics. Unlike the pub/sub service, the message broker service does not require another entity to subscribe to receive messages.

Relational Storage This service stores Software and Data Services data, including data required for user authentication, in related tables.

Short-Term Storage This services stores data from the Software and Data Services for a finite period of time, after which the data is deleted. Before deletion, the data is copied to Long Term Storage.

Long-Term Storage This service stores data from the Software and Data Services indefinitely, or until the data archiving policy dictates deletion.

Data Export This service orchestrates and controls data export.

Parser Service This service unpacks and parses data from external and internal sources, to be used by other Software and Data Services. The Parser Service does not expose its REST API to external TraCSS users.

Container Orchestration This service manages container orchestration.

Container Image Management This service manages container images.

DevSecOps Pipeline and Orchestration

This service manages the DevSecOps pipeline.

Visualization This service provides visualization capability for system administration activities.

Cluster Manager These services are related to the provisioning and management of the TraCSS government cloud infrastructure. Computing

Networking

Security

Load Balancer

Authorization and Authentication

This service ensures that users are properly identified before accessing TraCSS.

Web Application Server This service accepts HTTP requests and delivers website content in response.

Appendix D: Performance Requirements Summary (PRS)

The PRS establishes key elements of Contractor performance that represent “mission essential” service requirements, which are identified in the table below in the “Service Output” column.

The “Performance Standard” column represents the standard against which Contractor performance will be measured in relation to accomplishment of the corresponding service output.

The performance standard describes the minimum acceptable level of service by the Contractor for satisfactory performance. The “Acceptable Quality Level (AQL)” column displays the maximum allowable deviation from the performance objective, which, if exceeded, evokes the negative incentive specified in the table below.

Service Output

Performance Standard

Acceptable Quality Level (AQL)

Method of Assessment

Incentive/

Disincentive

Tested Code Code delivered under the order (including scripts and configuration files, where appropriate) must have substantial test code coverage and a clean code base.

Version-controlled, shared repository of code comprising the product, which will remain in the government domain.

Minimum of 90% test coverage of all code

Combination of manual review by COR or delegate and automated static and dynamic testing.

Test cases stress code beyond "happy path."

Incentive = option period considered if funding available and the need exists.

Disincentive = Corrective action plan to remedy a deficiency to be submitted to the COR and/or delegate for review

Properly Styled Code

Appropriate format guide for language.

0 linting errors and 0 warnings

Combination of manual review by COR or delegate and automated testing

Incentive = option period considered if to remedy a deficiency to be submitted to the COR and/or delegate for review

Deployed Code must successfully build and deploy into staging environment

Successful build and deploy to staging with a single command

Combination of manual review by COR or delegate and automated testing

Incentive = option period considered if to remedy a deficiency to be submitted to the COR and/or delegate for review

Documented All dependencies are listed and the licenses are documented. Major functionality in the software/source code or configuration file is documented.

Individual methods are documented inline using comments that permit the use of documentation-generation tools. An

Combination of manual review and automated testing, if available

Combination of manual review by COR or delegate and automated testing, if available

Incentive = option period considered if to remedy a deficiency to be submitted to the up-to-date system diagram (MBSE) that reflects the actual system is provided. A software bill of materials is provided.

Security OWASP Application Security Verification Standard 4.0, Level

Code submitted must be free of medium-and high-level static and dynamic security vulnerabilities

Clean tests from static and dynamic testing, along with documentation explaining any false positives

Incentive = option period considered if to remedy a deficiency to be submitted to the https://www.owasp.org/images/d/d4/OWASP_Application_Security_Verification_Standard_4.0-en.pdf

Appendix E: Deliverables

Item PWS

Reference…