Attachment 1 - DRAFT BMC3 Software Development Standard.pdf

DRAFT

i

Attachment 1

DRAFT BMC3 Software Development Standard

Broad Agency Announcement (BAA)

Space Development Agency (SDA)

Mission-Specific Application Prototypes (MSAP)

HQ085020S0002

June 26, 2020

Version 1.1 ii

1. Introduction

1.1 Purpose and Scope

1.2 System Overview

1.3 Referenced Documents

2. Project Definition

2.1 Project Scope

2.2 Project Assumptions

2.3 Architecture and Design Constraints

2.4 Other Project Constraints

3. Software Development Process Overview

3.1 Software Development Methodology

3.2 Software Development Organization

3.3 Roles, Responsibilities and Reporting

4. Guidance on Software Development Activities

4.1 Software Release Planning

4.2 Software Design and Development

4.3 Software Integration and Testing

4.4 Hardware-Software Integration and Testing

4.5 System Integration and Verification Testing

4.6 Software Quality Assurance

4.7 Software Configuration Management

4.8 Software Security

5. Software Engineering Environment

6. Intellectual Property

Appendix A. Acronyms

1. Introduction

1.1 Purpose and Scope

The purpose of the Software Development Standard (SDS) is to describe the software engineering processes employed as part of the development of the Battle Management Command, Control and Communications (BMC3) layer and other related program activities.

This SDS provides overarching guidance for all BMC3 software development activities.

Contractor Software Development Plan (SDP) documents shall be compliant to the SDS.

Exceptions and waivers, if any, shall be clearly documented and approved.

1.2 System Overview

1.2.1 Vision

The vision for the BMC3 layer is that it will integrate all of the functional layers in the National Defense Space Architecture (NDSA) to deliver capabilities to the warfighter that mitigate emerging threats and close time-critical kill chains. The BMC3 hardware module will reside on each satellite and will utilize software applications to direct higher-order functions, maintain a common operating picture and process time-sensitive data. It will also utilize the on-orbit mesh network and tactical communications provided by the Transport layer to transfer data and actionable intelligence to other air, space and ground nodes.

The BMC3 Software Platform, together with Space Vehicle Applications developed for this system, enable an operational commander to plan, coordinate, direct and control sensors and assets via the SDA constellation.

1.2.2 Mission

The mission of the BMC3 is to:

• Host mission-specific processing, algorithms, and applications across the SDA architecture layers and systems

• Provide a processing environment that supports automated system tasking and space-based forward mission data processing, as well as rapid reconfiguration in response to system threats

• Manage publish/subscribe service for rapid dissemination of information

• Provide a software framework that enables applications for BMC3 functions:

o Manage constellation o Develop and publish a common relevant operating picture (CROP) o Plan and control relevant sensors and other assets o Manage cyber defense

1.2.3 Goals

The goals of BMC3 include:

• Close time-critical kill chain for advanced threats

• Self-tasking and self-prioritization (for collection)

• On-board processing and dissemination

• Delivery of perishable space sensor-derived data products directly to the warfighter

1.2.4 Stakeholders

Involvement of the following stakeholders is critical to the success of this project:

• End users – BMC3 must respond to the needs of end users including mission commanders, operators and warfighters on the tactical edge. The agile software development process for applications requires frequent, close, intense cooperation with end user representatives.

• Other SDA layers – BMC3, by definition, interfaces with all of the SDA layers. In order to be successful, this project must have a clear understanding of interfaces and responsibilities with other layers.

1.3 Referenced Documents

1. DoD Enterprise DevSecOps Reference Design.

2. CWE Top 25 Most Dangerous Software Errors, https://cwe.mitre.org/top25/archive/2019/2019_cwe_top25.html, accessed March 20, 2020

3. OWASP Application Security Verification Standard, https://owasp.org/www-project-application-security-verification-standard/, accessed March 20, 2020

4. DoD Cybersecurity Maturity Model Certification, https://www.acq.osd.mil/cmmc/draft.html, accessed March 20, 2020

5. Scaled Agile Framework, https://www.scaledagileframework.com/, accessed March 20, 2020

6. Software Development Standard for Mission Critical Systems, Aerospace Report No. TR-RS-2015-00012, March 17, 2014.

7. Program Office Guidance for Acquisition of Systems Developed Using Agile Software Development, Aerospace Report No. ATR-2018-00552, January 30, 2018.

8. Unified Architecture Framework (UAF) by the Object Management Group (OMG), see https://www.omg.org/uaf/index.htm, access April 30, 2020 https://cwe.mitre.org/top25/archive/2019/2019_cwe_top25.html https://owasp.org/www-project-application-security-verification-standard/ https://owasp.org/www-project-application-security-verification-standard/ https://www.acq.osd.mil/cmmc/draft.html https://www.scaledagileframework.com/ https://www.omg.org/uaf/index.htm

2. Project Definition

2.1 Project Scope

The BMC3 software development project will augment and eventually replace human-intensive ground-based satellite operations and data processing. The SDA BMC3 is a battle management system that runs in space using onboard processing in a proliferated LEO constellation of hundreds of satellites.

2.1.1 In Scope

• Full lifecycle software and firmware development to meet project goals

• Requirements and specifications decomposed and traced to epics, features, and user stories

• Software architecture and design using model-based standards and techniques (e.g. Unified Architecture Framework [8] and SysML)

• System interface control documents (ICDs) and/or application programming interface (API) with other SDA layers

• ICDs and/or APIs with external battle management systems and other mission partner systems such as (but not limited to):

o C2BMC for Missile Defense Agency o EGS for Air Force o TITAN for Army o CEC for Navy

• Integrated Development Environments (IDE) and Software Development Kits (SDK) interacting with the containerized software platform with associated hardware requirements. The intent of the IDE and SDK is to provide utilities for application developers that is a close enough approximation of the flight environment that problems that arise later should predominantly be integration challenges.

• Technical documentation (possibly online or integrated with software).

• Sample mission applications and datasets to demonstrate capability and refine system requirements.

• Demonstration and testing of the software platform and sample applications in the Hardware-in-the-Loop (HWIL) and Software-in-the-Loop (SWIL) facility at the U.S. Naval Research Laboratory in Washington, DC (Initial Operating Capability:

TBD).

2.1.2 Out of Scope

• Development of data fusion algorithms and application code for other layers

• Level 0 on-orbit processing for sensors. It is assumed that sensors will have their own low-level processing capabilities.

2.2 Project Assumptions

The BMC3 system is based on the following assumptions:

• The majority of BMC3 capabilities and related processing run in space.

• Mission priority, technical feasibility and cost trades may drive certain BMC3 capabilities to reside within the ground architecture (temporarily or permanently).

• Autonomy is required to manage uncertainty and rapidly adapt to threats in a highly complex dynamic system with hundreds of nodes.

o Nodes constantly moving in and out of line of sight to targets o Intermittent connectivity between nodes o Node and sensor degradation and failure from natural causes o Attrition and attacks on nodes and sensors o Maneuvering targets that are fast and dim

• BMC3 handles autonomy at constellation and node levels.

• BMC3 can interface with external systems/segments (e.g. tasking bus).

• For most applications in most modes, communication will likely occur over a packet-switched network. For time-critical applications such as missile defense, circuit-switched networks may be used.

Software development is based on the following assumptions:

• Warfighter/end user representatives are available to guide development of applications.

• HWIL and SWIL facilities are available for the development, testing, V&V, and risk mitigation of the BMC3 hardware and software (NET: End of FY21).

• BMC3 capabilities are developed and matured incrementally using the Agile methodology, following continuous integration and continuous delivery best practices.

2.3 Architecture and Design Constraints

2.3.1 Architecture Principles

Industry best practices in software architecture should be followed, including but not limited to:

• Modularization and componentization, with components that are highly cohesive internally and loosely coupled with one another. Containerized microservices embody the latest evolution in component-based architecture.

• Standards-based interfaces, especially machine-to-machine APIs. In particular, REpresentational State Transfer (REST) interfaces with clearly-defined primitives (e.g. GET/PUT) help ensure interoperability across software components regardless of their implementation platform, programming language, and vendor product.

• Layers of abstraction, such as Infrastructure as a Service (IaaS) / Platform as a Service (PaaS) / Software as a Service (SaaS). SDA envisions that IaaS layer provides software defined networking, allowing Internet Protocol-based network traffic between all system components. The PaaS layer includes a “zero trust” encrypted service mesh to provide flexibility, observability, and security.

• Decoupling application and data. Enterprise and mission-critical systems are being transformed from application-centric towards data-centric architectures to ensure data remains enduring assets even as applications come and go.

BMC3 software design and development should also follow sound architecture patterns, which are solutions to recurring problems. Many cloud-native architecture patterns have been documented extensively in the public domain. Within the BMC3 context, the following patterns are especially relevant in addressing some of its unique challenges such as autonomy and resiliency:

• The reflective-and-base-subsystem model, also known as supervisor-worker subsystem model, stipulates that an autonomous system comprises two subsystems, the base-level / worker subsystem and the reflective / supervisor subsystem, with the latter performing oversight functions of the former. This allows critical mission functions be monitored for abnormality, fault-tolerance, and cyber security purposes.

• Leader-election patterns in distributed computing, ensures coordination of actions performed by a collection of collaborating nodes.

• The operator pattern, which follows a declarative (as opposed to procedural) style for controlling resources at runtime. As opposed to telling the system how to manage the resources, the pattern expresses the desired outcome (e.g. two replicas of the service should be running with the expected minimum latency), and leave the "how" part to the controller (e.g. load balancing, spawning new instances, etc.)

• The event-driven architecture, now widely used in cloud-native architectures, can decouple data producers and consumers and avoid point-to-point integrations.

Complex Event Processing (CEP) engines, for example, are often used for processing events with geospatial and temporal attributes. BMC3 assumes an event-driven architecture with intelligent agents implemented as containerized microservices communicating via a message queue.

2.3.2 BMC3 Architecture Context

A notional high level architecture of the BMC3 software system is shown below. The Plan & Control Subsystem (PCS) performs the knowledge-driven Monitor - Assess - Plan

- Execute (MAPE-K) loop that manages all BMC3 applications / services as well as the underlying hardware and software platform. The PCS is responsible for the following:

• Monitor the health and status of BMC3 apps and services (e.g. fail-over, software upgrades)

• Assess the effectiveness and well-being of the apps and services (e.g. is the fusion algorithm effective?)

• Plan and prioritize the tasks based on user requests and allocate resources accordingly (e.g. allocate more processing power to urgent processing task)

• Collaborate with other vehicles in constellation management

• Maintain cybersecurity posture and mitigate potential cyber threats (e.g. security patching, intrusion detection)

As such, the PCS requires a higher degree of protection and assurance (e.g. separate hardware/TPM module and network boundary, etc.)

The BMC3 mission apps / services are the regular workloads that run on a container orchestration platform. The services are instantiated and managed by the PCS based on mission priorities and resource availability.

2.3.3 Design Constraints

Since the system and hardware dependencies will be abstracted out, applications can be developed using more agile software development methods. Examples of applications include Common Relevant Operating Picture, HGV/Missile Defense, Custody, Cyber Defense, and Tactical Communications.

The architecture will have strong specifications for the software platform that forms the middle layer between hardware and applications. Specifically, the platform will require developers to use Open Container Initiative compliant hardened immutable containers and adhere to API and messaging interface standards. Strictly specifying the software platform will enable flexibility in both hardware evolution and software applications while ensuring the software system integrates easily.

Given the enormous attack surface of a globally distributed system with hundreds of nodes in space, on the ground, and in the air, strong security specifications will be enforced at the architecture level as well. Specifically, only DoD hardened containers will be used and will come with sidecar proxies in a service mesh to manage request routing, logging, telemetry and security policy.

(SVAs)

BMC Architecture Layers

Running a battle management system using onboard processing in a proliferated LEO constellation imposes a number of unique design constraints. These constraints are the "canvas" on which software will be "painted." Unlike a terrestrial cloud computing environment, SDA has a limited number of nodes which cannot be easily scaled out.

These nodes have relatively limited compute resources, electrical power, and communication bandwidth. Data rates between nodes are likely to be less than terrestrial data centers. Connectivity between nodes is not continuous so the software platform must be partition tolerant. At any point in time, the SDA constellation will include nodes from different "tranches" with different hardware capabilities, so the nodes will be heterogeneous. Finally, the orbital motion of nodes requires that compute clusters adjust to nodes constantly entering and leaving the cluster while computation is in progress.

This dynamic geotemporal scheduling of nodes and clusters is necessary in order to maintain custody of targets on the ground and to track targets in flight. While the intention is to use industry standard data processing frameworks where possible, it is expected that they will need extensive modifications in order to work in this unique environment. It may not be possible to have clusters that span multiple nodes.

2.4 Other Project Constraints

By strongly specifying the middle layer software platform, the BMC3 architecture enables competition for hardware and software applications. SDA's intention is to specify an architecture that enables the data layer, infrastructure, platform, and applications to be acquired separately if necessary, so as to select the best-of-breed solutions in each area.

3. Software Development Process Overview

3.1 Software Development Methodology

The BMC3 software development process is based on the DoD Enterprise DevSecOps Reference Design (DevSecOps). This process unifies development, security and operations using agile development to deploy software at the "speed of operations." The goal is to provide "just enough process" while leveraging contractor best practices. Key concepts of DevSecOps include automated build and test, continuous integration/continuous delivery, small frequent incremental releases, cloud computing and software containers. DevSecOps requires "everything as code" including configuration, security, and policy so that development can be implemented as a highly automated "software factory."

BMC3 will adapt and extend DevSecOps to the unique computing environment of the SDA constellation. Specifically, while cloud technologies will be used to develop software, the operational environment resembles nodes on a wide area network (WAN) rather than a commercial cloud or data center due to the relatively low data rates between nodes.

3.2 Software Development Organization

Management of BMC3 software consists of the government/FFRDC program office, the contractor development teams, the software factory, and the HWIL/SWIL test and evaluation team.

3.2.1 Government/FFRDC Program Office.

The program office consists of government and FFRDC personnel who oversee the development process. They define requirements, architecture, product roadmaps, schedule, deliverables, and specifications on product and process including interfaces and acceptance tests. All source documents are envisioned as lean, concise and high level.

Requirements are usually specified as stories and epics. The focus is on frequent interaction with development teams, not extensive documentation. The program office also maintains the central code repository and fault tracking system.

3.2.2 Contractor Development Teams

Contractor development teams write code and unit tests. While they follow a customized DevSecOps process, they have latitude to employ their own best practices for software development. In the early stages, it is likely that one contractor will do initial development of the software platform. Once the platform is mature, software development may be accomplished by multiple contractor teams. Development teams will normally operate within the Software Factory. Some initial algorithm and prototype development may be done by teams with special domain knowledge outside of the Software Factory. Examples include 3D fusion algorithms and constellation planning and control.

3.2.3 Software Factory

The DevSecOps Software Factory is responsible for setting up and maintaining the unique development environment and pipelines for SDA. This include hardened containers, sidecar security containers and associated code. Contractor development teams will normally operate within the Software Factory using its established tools and processes. In most cases, software will be developed in an unclassified environment and then replicated to separate environments with higher classification levels. The Software Factory Continuous Integration / Continuous Delivery (CI/CD) automated pipeline will update the replicated instances at the same time the code is committed in the unclassified environment.

3.2.4 HWIL/SWIL Test Lab

The HWIL/SWIL Test Lab is responsible for developing and running a simulated test environment including engineering models and flight hardware as they become available.

The HWIL/SWIL Lab performs integration testing as well as load testing and penetration testing.

3.3 Roles, Responsibilities and Reporting

The BMC3 development team should have a Lead Software Engineer (LSWE) role for leading and managing software activities. The LSWE should report to the Program Manager, the Chief Engineer, and government customers throughout the engineering lifecycle activities outlined in Section 4. The LSWE should maintain and execute this SDS. If the development team follows the Scale Agile (e.g. Scrum of Scrums) methodology, the LSWE should also be taking on the Release Train Engineer (RTE) role to facilitate the release train events and processes, communicate with stakeholders, escalate impediments, and drive continuous process improvement. This is critical to ensure the multiple self-organizing and self-managing teams do not work in isolation.

The following roles are typical in software development activities based on an Agile methodology (e.g. Scrum) with emphasis on CI/CD.

Role Responsibilities

Lead Software Engineer • Provides oversight for all software teams

• Lead software risk / impediment tracking and mitigation

• RTE role (Communicate to stakeholders, escalation, process improvement)

• Facilitates system / release train Agile cadence (e.g.

release planning, demo, retrospective, reviews)

• Oversees CI/CD activities

Product Owner • Manages the grooming and maturing of product backlog (at release and sprint levels), including changes thereof

• Serves as the voice of the customer w.r.t. user story and activity prioritization

• Participates in cross program coordination

• Defines epic/feature/story expectations and acceptance criteria (“definition of done”)

Software Architect • Responsible for overall architecture and design, including quality attributes and trades in architectural decisions

• Lead new technology exploration and insertion

• Participate in cross-team / IPT / external architecture coordination and interfaces

• Responsible for generation and QA of model-based architecture artifacts (such as those based on SysML or

UAF)

Scrum Master • Team lead / tech lead in Agile lifecycle to ensure the development team is functional, focused and productive

• Serves as voice of the development team and shields the latter from interferences and distractions

• Ensures the SDS and related processes are followed

• Identifying and raising risks / impediments

• Facilitates work estimation (e.g. using story points)

• Runs the Sprint cadence events (daily scrums, sprint planning, sprint demo, retrospective, etc.)

Software Engineer • Software design, development, and unit/component level testing

• Follows approved SDS and approved development processes (e.g. TDD)

• Participates with backlog decomposition and maturation

• Develops and executes CI/CD automation scripts and tests

• May have different variations such as o DevSecOps engineer o Data engineer o UX engineer o Software security / cybersecurity engineer

Test / IV&V Engineer • Defines full specifications of unit, integration, and formal quality tests necessary to satisfy acceptance criteria

• Review and obtain approval from customer on test acceptance and approval

• May participate in test execution and witnessing

• Promotes test automation

• Reviews test results, creates and resolves Defect Reports (DRs) and issues

• Maintains testing tools, data, and environments

In addition, to facilitate fast decision-making in the Agile lifecycle, the software team should be augmented with cross-functional roles such as:

• User / mission representative, who understands mission area tasks and activities and can provide end user perspective;

• Security / RMF process representative, who understands enterprise security requirements, RMF processes towards the ATO, and can guide the team in preparing evidence and artifacts to meet the applicable security controls

• Contracting representative, who can promptly take contract actions driven by requirement or scope changes to minimize schedule impact.

4. Guidance on Software Development Activities The BMC3 software development project should follow the guidance on the following activities throughout the software development lifecycle.

4.1 Software Release Planning

Modular, layered and open architecture (section 2.3) coupled with the DevSecOps development methodology (section 3.1) should enable a frequent, incremental release strategy.

BMC3 software should follow a regular, time-boxed release schedule (e.g. every 3 months) to deploy software modules into the HWIL/SWIL integration environment.

Each release should start with an (ideally face-to-face) Release Planning event to define release goals, estimate levels of effort, and acceptance criteria. The release should end with Release Demo/Retrospective events.

Given the complexity of the BMC3 software architecture with diverse hardware and software platforms and various modeling and simulation environments, it is very likely each release will involve multiple Agile scrum teams, each with multiple sprints. It is highly recommended that the Scaled Agile Framework or SAFe [5] or similar methodology be followed to coordinate deliverables from all teams into an Agile Release Train (ART) with a synchronized sprint cadence.

A release roadmap should be developed to forecast and communicate future deliveries and milestones over a planning horizon.

4.2 Software Design and Development

Under an Agile / Scaled Agile development methodology, the BMC3 software design should be driven by a Product Backlog populated with Epics, Features, and User Stories, all of which are derived from high level customer requirements. The backlog items that are prioritized for near-term increments should be more concrete and low-level to drive detailed design and development, while future functionality can afford to be more abstract.

While the Agile methodology advocates working prototypes over comprehensive documentation, the BMC3 software, especially for the space segment, operates in a constrained hardware environment, and should maintain traceability to overarching system architecture models. Consequently, BMC3 software teams should develop a minimum set of software architecture and design artifacts based on a standard framework (e.g. SysML, UML), and should integrate these artifacts with overarching model-based artifacts at the system level following MBSE and Digital Engineering principles. For example, deployment diagrams showing what software components reside in what hardware modules should be used to inform the development team.

The BMC3 software design and implementation should be platform-independent, following cloud-native principles and patterns as mentioned in Section 2.3.

In addition to an agreed-upon scrum cadence, Software development teams should document their development practices and design decisions upfront, to ensure consistent behavior among developers and testers. Such practices may involve:

• Programming language(s) of choice

• Integrated Development Environments (IDE)

• Cloud environments

• DevSecOps tool chain, including Software CM tools (e.g. GitLab), test orchestration (e.g. Jenkins CI), code review tools, etc.

• Team collaboration tools and environments

• Software frameworks of choice (e.g. Spring, Anaconda, NodeJS)

• Logging, and other commonly used 3rd party libraries

• Unit testing tools

• Simulators / emulators

4.3 Software Integration and Testing

Software integration and verification occurs throughout the lifecycle and is based on Test-Driven Development (unit tests) and Behavior-Driven Development (acceptance tests). Automated test scripts are written before software is developed. Development continues until the code passes all the tests. Acceptance tests are defined and written at the program office level to ensure that a software module's behavior has the required high-level functionality. Unit tests are written and managed by software engineers on the contractor development team and ensure low-level functionality at a fine-grained level.

Wherever possible, the development team should perform testing on the target computer system in a flight-like configuration. All test results should be recorded and stored in the configuration management system.

4.4 Hardware-Software Integration and Testing

Once a software module has passed all unit and acceptance tests, it is transferred to the HWIL/SWIL test lab for integration testing. During this phase of development, the module is deployed into a simulation environment where interactions between modules can be tested in a flight-like environment, including faults. Load testing and cybersecurity testing will also occur during this phase. Flight software certification standards will be developed to ensure that the software meets mission needs and does not create system-level faults before it is uploaded to the spacecraft.

4.5 System Integration and Verification Testing

Software distribution and deployment is accomplished using an industry standard container orchestration system. The SDA constellation will have hundreds of nodes, each with a BMC3 compute module. Each module may run multiple applications, each in its own container. A container orchestration system is necessary to coordinate the deployment, configuration, update, scaling and management of thousands of containers on hundreds of nodes.

Applications are deployed using a manifest file, which determines how the applications are configured and how they perform. The container orchestration system software should be able to perform rolling updates and monitor applications to make sure they are functioning as specified. This system should have a self-healing capability which is important because individual SDA nodes may degrade or fail over time. The system should also have the capability to auto-scale the number of nodes running a particular application in response to increased demand.

The BMC3 software will most likely need to extend the container orchestration software to handle issues which are unique to SDA. For instance, processing demand will be highly localized over certain regions of interest. Nodes are constantly moving in and out of those regions due to orbital motion and the rotation of the Earth. Deployments must include geospatial temporal scheduling to address this need. Deployments must also account for a data rate between nodes, which may be slower than what is found in modern data centers. In order to respond to time-critical threats, container orchestration must interact with a planning and control executive agent to adjust the deployment for fast-moving maneuverable targets. Finally, deployments must be integrated with advanced cybersecurity monitoring agents to detect and defeat network intrusions from adversaries.

4.6 Software Quality Assurance

The software quality assurance approach is based loosely on [6]. The development team should conduct ongoing evaluations at regular times of software development processes, products, work products, and services to assess adherence to process standards in accordance with the Software Development Standard (and contract). The development team should also assess that each software product required in the SDS (and contract) exists, has undergone peer reviews, product evaluations, testing (if applicable), and undergone corrective action for all identified discrepancies. The development team should also ensure continued consistency among all software-related plans including the SDS, Software Test Plan, and Software Master Build Plan. The development team should also provide feedback to SDA and other affected groups on evaluation results, issues status, and discrepancy change reports.

Quality assurance evaluations should be conducted by a group that does not report to the Lead Software Engineer in charge of development.

The development team should implement a corrective action system that lists each discrepancy detected in software under any level of configuration control above the level of the individual development team. The development team should demonstrate that action is initiated on each discrepancy and change report, and that the change is tested to determine whether the discrepancy is resolved and tracked to closure.

4.7 Software Configuration Management

The configuration management approach is based on [6]. The development team should implement a software configuration management system. The development team should identify the entities to be placed under configuration control, including at a minimum

• Products specified in the SDS (or contract)

• All elements of the software engineering environment

• All elements of the software integration and qualification test environment, including test results The development team should implement an identification scheme that includes version, revision and release status. Past versions should be maintained throughout the life of the contract and delivered to the government at the end of the contract.

The development team should identify levels of configuration control and persons or groups with authority to make changes and authorize changes at each level. The development team should establish procedures for checking entities in and out of the configuration management system and resolving conflicting updates.

4.8 Software Security

BMC3 software architecture should use Defense in Depth principles to minimize the attack surface and ensure mission functions may be performed under persistent and advanced cybersecurity attacks.

4.8.1 Build Security In

BMC3 software development should follow sound software security best practices to “build security in” and minimize the Common Weakness Enumeration (CWE) Top 25 Most Dangerous Software Errors [2]. Such practices may include:

• Train software developers in writing secure code

• Security by design: follow good security design patterns

• Follow sound secure coding guidance

• Use verification methods and tools to ensure secure development requirements are met. The OWASP Application Security Verification Standard (ASVS) [3], for example, provide a good basis for this.

4.8.2 Security Services

BMC3 software architecture should include security services for identification, authentication, and authorization (IAA) for both ground and space software platforms.

The security services should be integrated vertically across hardware, hypervisor, operating system, software platform, and software applications.

Sensitive data should be protected both at rest and in motion, using encryption, transport layer security, network security methods, cross-domain services, etc.

The security services should be supported by approved cryptographic components, trusted computing modules, and anti-tampering to ensure confidentiality, integrity, and availability.

4.8.3 Software Assurance

BMC3 software development should follow sound software assurance mechanisms for cybersecurity, such as:

• Vulnerability scans, using the latest tools from the industry

• Security testing and verifications, including pen testing

• Secure software supply chain management, especially when it comes to the use of free open source software. Bodies of evidence for software vulnerability should be kept and updated.

Many of the practices have been incorporated into DoD DevSecOps guidance [1].

4.8.4 Software Security Assessment

BMC3 software development should be assessed in accordance with DoD Instructions 8510.01, Risk Management Framework (RMF) for DoD Information Technology (IT).

The framework leverages the NIST SP 800-53 security control catalog and advocates incorporating security early and continuously throughout the acquisition lifecycle. In particular, BMC3 software security should not merely focus on meeting one-time assessment requirements to satisfy the security controls, but should ensure there are continuous monitoring capabilities at runtime that assess overall system security posture, identify anomalies and attacks, and take rapid mitigation actions. Survivability measures should also be considered to enable graceful degradation under cyber-attacks.

Additionally, DoD has recently released Version 1.0 of its Cybersecurity Maturity Model Certification (CMMC) [4]. The CMMC is a framework that “is designed to provide increased assurance to the DoD that a DIB [Defense Industrial Base] contractor can adequately protect CUI [Controlled Unclassified Information] at a level commensurate with the risk, accounting for information flow down to its subcontractors in a multi-tier supply chain.” SDA software development in the future may be required to be CMMC certified at the designated level.

5. Software Engineering Environment The standard for the software engineering environment is based on [6]. The development team should document the software engineering environment including facilities, hardware, software, firmware, procedures and documentation needed to perform software engineering. This includes tools for requirements management, architecting, designing, controlling, generating, verifying and loading the software. Examples include computer-aided software engineering (CASE) tools, requirements management tools, architecture modeling tools, compilers, assemblers, linkers, loaders, code analyzers, path and coverage analyzers, operating systems, debuggers, simulators, emulators, configuration management tools, discrepancy and change reporting tools, measurement tools, unit test case generators and other unit test tools, documentation tools, and database management systems.

6. Intellectual Property The government will retain unlimited rights or government-purpose rights to the maximum extent possible. While ownership may not be possible, access to the source code is needed so it can pass through the CI/CD pipeline before being added to the ecosystem. If it does not pass through the pipeline, it will not be considered for the ecosystem.

Because multiple companies may serve on a product team(s) and contribute their intellectual property to the overall code base, the additional build-out is considered government-owned. The government will work to protect individual companies’ intellectual property to the maximum extent possible.

Appendix A. Acronyms API Application Programming Interface

BMC3 Battle Management Command, Control, and Communications

CI/CD Continuous Integration / Continuous Delivery

CM Configuration Management

DevSecOps Development, Security, and Operations

EGS Enterprise Ground System

HGV Hypersonic Glide Vehicle

HWIL Hardware in the Loop

ICD Interface Control Document

IDE Integrated Development Environment

IPT Integrated Product Team

IV&V Independent Verification and Validation

MDA Missile Defense Agency

PCS Planning and Control Subsystem

RTE Release Train Engineer

SDA Space Development Agency

SDS Software Development Standard

SVA Space Vehicle Application

SWIL Software in the Loop

TDD Test Driven Development

UX User Experience

1.3 Referenced Documents

2.4 Other Project Constraints

3.3 Roles, Responsibilities and Reporting