Achieving Mission Resilience for Space Systems
Space systems need enhanced resiliency to ensure performance
of critical functions and overall mission operations during a
cyberattack. Aerospace is investigating various approaches to
achieving such resilience for current and future programs.
Space assets are an integral part of cyberspace. As such, they are directly and indirectly connected to supporting systems with varying levels of assurance and security. These highly distributed systems provide a broad attack surface to adversaries. Additionally, the reuse, complexity, and interoperability of spacecraft components often results in systems with interconnected legacy components (whose security posture is unknown) and insecurely configured hardware and software. These systems provide minimal support for resiliency and countermeasures and limited, if any, cyberspace situational awareness.
As part of its efforts in space-program research, guidance, and experimentation, The Aerospace Corporation is developing a set of architectural and operational recommendations to enhance space mission resilience against cyberattacks. These include the application of architectural frameworks, constellation design practices, software engineering methods, and cyberspace command and control models.
Architectural Frameworks for Resiliency
The software architecture is the design blueprint that specifies the components of a system, the organization of those components, and the rationale for why the particular component structure will meet system requirements and stakeholder expectations. An architecture that is incorrectly or poorly defined often leads to costly reimplementation, induced complexities, legal challenges, and even project failure. Far worse, even if the system is eventually built and deployed, poor architectural design may introduce weaknesses that render the system vulnerable to a multitude of cyberattacks.
An organized approach to evaluating a software architecture can reduce the cost, schedule, and cybersecurity risks that result from improper design. Aerospace has developed a framework to do just that.
The architecture framework includes a set of “dimensions”—categorized lists of focused questions that probe different aspects of the software architecture during each phase of a program’s lifecycle. These initially addressed general qualities such as flexibility, availability, and interoperability as well as specific space concerns such as reprogrammability and information assurance. A resiliency dimension has been added to specifically address the growing threat of cyberattacks. It covers complexity, integration, priorities, degraded operation, and failure recovery. A sufficient cyber defense must consider which functions are critical to accomplishing the mission, which components and subsystems accomplish those functions, and how are those components and subsystems organized. Resilience must be engineered in the context of attacks that can jeopardize mission-critical functions and capability. Of particular interest are attacks that result in loss of data, loss of command and control, or loss of availability or that involve jamming of communications or telemetry, injection of spurious input, and spoofing or deception of received signals.
More work is required to fully evaluate the resiliency of space systems to cyberattack. Lower-level implementation, integration, and the operational environment are additional areas that need to be considered.
Several programs have already undergone architecture evaluations that included the resiliency dimension, and the experience gained has been invaluable in strengthening the understanding of resiliency and how it is achieved and assessed in space architectures. Aerospace is continuing to refine the resiliency dimension by applying the framework to more programs and incorporating the results of ongoing internal research.
Resilient Constellation Designs
A functional concept of cyberspace operations and the operational environment. Courtesy of U.S. Air Force.
Space segment architectures have traditionally focused on satellites designed to meet large sets of static mission requirements through a projected service life of ten years or more with limited update capability. Increasingly, however, system designers have begun to recognize that these space systems need to be modified in a shorter time span and need to accommodate changing mission requirements and technology advances. As a result, the perspective of what satellites are has begun to change. Satellites are no longer seen as massive pieces of durable hardware, but rather as systems providing a series of services—e.g., acquiring useful data, storing it, packaging it into higher-level products, and downlinking it to users or ground sites. By separating the services required of space systems from the payloads that provide them, program architects can develop systems with inherently greater resilience.
One such approach is known as fractionation. In a fractionated architecture, the traditional monolithic satellite is replaced by a spaceborne cluster of interconnected modules. These modules operate on a common wireless network that allows them to share resources (in this context, shareable resources are the services provided by space systems—data processing, data storage, and space-to-ground communication). Free-flying payload modules can be supported by one or more infrastructure modules that simultaneously provide services to all payloads within the cluster. Common infrastructure modules can be maintained, exchanged, and upgraded independently from the payload modules and dynamically tasked based on changing conditions (e.g., updates to payload priority, mission criticality, or the current state of the cluster).
A fractionated architecture offers significantly more flexibility, responsiveness, robustness, and survivability than a traditional monolithic spacecraft. To begin with, the services provided by the spacecraft are no longer physically connected; therefore, modules can be developed, manufactured, integrated, and tested in parallel. This functional partitioning, combined with the smaller size of the modules, leads to shorter design and build cycles and more frequent opportunities to insert new technology. Modules can be launched separately, which implies shorter times to initial operating capability and a reduced risk from a single catastrophic launch failure.
Fractionated architectures also offer greater resilience against cyberattacks because of the reconfigurable nature of the network. Real-time network management and fault tolerance can provide multiple routing paths around the cluster, including rapid and autonomous reconfiguration in the face of network degradation, component failure, or the addition or removal of resources. Network-level safe modes that protect the cluster from cyberattack (or switch to modes that continue to operate through the cyberattack) can be coupled with vehicle-level safe modes to ensure continued safety of the network as well as the individual modules. These are all based on the cluster’s capability to autonomously reconfigure itself to retain safety- and mission-critical functionality despite network degradation or component failures.
Some technical and operational gaps must be addressed before fractionated architectures can be widely introduced. Current concepts for fractionation require the development of advanced technologies (e.g., wireless communications, networking, information assurance, cluster flight), though upfront work in standardization of interfaces and protocols will reduce the development complexity for future spacecraft systems. Current concepts also require a significant amount of onboard autonomy, which presents significant challenges in the areas of software development; fault detection, isolation, and recovery; network management; and verification/validation of safety-critical, distributed, real-time, and dynamically reconfigurable software. Also, although they are highly resilient, fractionated systems may be inherently more vulnerable to cyberattack than traditional spacecraft because they replace the internal spacecraft harness with a wireless network. Despite these challenges, the potential benefits in flexibility, survivability, and resilience continue to make fractionation an attractive option for future architecture studies.
Flight Software Resiliency
Spaceflight systems will need to evolve to include operating strategies to mitigate the emerging cybersecurity threat. In the near term, additional computing resources can be used to implement mitigation techniques that have been proven effective terrestrially. In the medium term, flight systems will need to redefine mission assurance, fault management, and the notion of safe mode to include resiliency. Future systems will need to have a risk-based approach to both autonomous and human-in-the-loop fault management that preserves operating capability. Finally, the long-term solutions for flight systems will probably incorporate new technologies that provide detection and avoidance that are still very much research ideas. High-level design tools will need enhancements to appropriately model the cost/benefit trade-offs for cyberattack resilience.
Some of the near-term mitigations that can be applied to flight systems include:
- Isolation kernels. Future flight systems will include operating systems (kernels) that provide separation of privileges, memory, and other resources. Current systems rely on monolithic real-time kernels that do not provide many of these protections.
- Signed code. Flight software disk images could be digitally signed by the factory and protected from tampering. This could prevent the uploading of an unauthorized image and protect the integrity of the image stored onboard the satellite. Restarting an onboard computer using a signed disk image may afford the opportunity to return a system to a known good state.
- Address-space randomization. The memory layout of flight software could be randomized each time a flight processor is rebooted. This would make it more difficult for a cyberattack to make assumptions about the memory locations and the offsets needed to exploit an existing flaw in the software.
- Bus-spoofing protections. Most modern high-performance bus technologies are packet-switched, rather than broadcast-based. Many of these bus standards do not include protections against spoofing the source of information on the bus. Spoofing the source implies that a sender on the bus is masquerading as another sender. Spoofing protection could, for example, prevent a rogue subsystem from sending a false attitude control update to the main flight processor.
None of these features is new to terrestrial systems, yet they are rarely seen on flight systems. Inserting them into new flight systems offers an opportunity to reduce the risk and impact of cyberattack in an affordable, evolutionary way.
Some of the solutions for mitigating nonmalicious faults may also apply to malicious faults. Traditional techniques for handling radiation-induced single-event upsets have included memory scrubbing and periodic reboots of the flight processor. Variations of those approaches may work equally for malicious faults. One could envision scrubbing (rewriting) the memory containing the flight-software object code with a copy from the stored signed image. Periodic reboots might also serve to disrupt a transient/memory-resident malware attack.
Aerospace has developed a framework for evaluating software architectures. This framework includes a set of dimensions, or categorized lists of focused questions to ask about the software architecture. This flowchart provides an example of how questions for the resiliency dimension might be defined at each level in the evaluation framework.
Cyber defense policymakers and system architects are working to achieve a level of operational resiliency similar to that afforded to traditional assets. This requires a cyberspace command and control system and a skilled team to maintain operational status and situational awareness. Because of the time and space compression of cyber warfare, the command and control system must be designed to send and process data at speeds consistent with cyber warfare engagements.
One way to achieve the necessary rapid response is through a peer-processing architecture designed with a native publish-and-subscribe messaging system and distributed virtual shared data spaces. The operational structure of such an architecture could be based on virtual cells that model the physical cells in a typical military command center.
Inherent in this architecture is the ability to rapidly move functional roles and cells to other locations on the network. This would allow, for example, a cell to transfer its state to a node running as a peer cell on another network. The continual movement of cells (and critical applications) via state transfer around a network increases resiliency against attacks by making the cells more difficult for attackers to find. A related strategy involves a new version of an operational cell.
Another component of the cyberspace command and control architecture is the engineering cell. The engineering cell has many roles, but one of its most important is to manage honeypots and deception strategies. A honeypot is an area of a protected network or computer resource designed to be infiltrated; the attacker believes he has uncovered a vulnerability, when in fact, his actions are being recorded and traced, without comprising any real security. In the case of the engineering cell, a honeypot might deploy, for example, an emulated air defense system using virtual machines. It would behave like a real air defense system, and could even autonomously respond to cyberattacks while simultaneously executing feint air defense actions, providing a further illusion of its legitimacy.
Effective mission resilience enables mission success. Program architects need to determine the critical aspects of space systems and apply innovation and rigor to ensure that they execute exactly as intended. Engineering decisions should be tied to the value of a mission and the asymmetric nature of the cyber domain. Although it is not feasible to try to counter all possible attacks, a billion dollar investment should not be at risk from a five-dollar attack. Achieving mission resiliency in a contested cyber domain requires the appropriate balance of architectural, operational, and defensive considerations applied across all space system segments.
Developers can no longer assume that space systems are isolated, pristine, and uncompromised, but must work to apply architectural frameworks that address resiliency. They need to think about how systems interact and are extended when defining requirements and acceptance criteria. Faster acquisition models are needed, along with new architectures that are truly modular and extensible. Most important, developers need to understand that the traditional battle space can no longer be viewed as a collection of discrete realms. Space, ground, and user segments are all nodes on a network—interconnected and interdependent.
Where is the cyberspace domain? Cyberspace is embedded in military and intelligence systems—the air, land, maritime, and space domains. Operations occur in whole or in part in cyberspace. This includes the use of computers, sensors, busses, displays, controllers, local area networks, hardware, firmware, and software (including operating systems and databases, middleware, and applications). The communication/networking infrastructure connecting these are data links, the Global Information Grid, and the Internet.
The author would like to thank James Donndelinger, Robert Lindell, Steven Meyers, John Nilles, Peter Reiher, Gregory Richardson, John Sarkesain, Mario Tinto, Alan Unell, and Richard Yee for their contributions to this article.
Aerospace Technical Report ATR 2011(8413)-1: Real-Time Distributed Correlation for Cyber C2 and Situational Awareness (The Aerospace Corporation, El Segundo, CA, 2011).
Air Force Doctrine Document 3-12, “Cyberspace Operations” (U.S. Air Force, July 15, 2010); www.e-publishing.af.mil.
Air Force Science and Technology Strategy and Plan 2010 (U.S. Air Force, Jun. 3, 2011).
Air Force Technology Horizons, http://www.af.mil/information/technologyhorizons.asp (as of Dec. 7, 2010).
E. Al-Ammar and J. Fisher, “Resiliency Assessment of the Power System Network to Cyber and Physical Attacks,” Power Engineering Society General Meeting (2006).
K. Bowman and J. Tschanz, “Resilient Microprocessor Design for Improving Performance and Energy Efficiency,” 2010 IEEE/ACM International Conference on Computer-Aided Design (2010).
O. Brown and P. Eremenko, “The Value Proposition for Fractionated Space Architectures,” Space 2006 (AIAA 2006); AIAA-2006-7506.
R. Caralli et al., “Introducing the CERT Resiliency Engineering Framework: Improving the Security and Sustainability Processes,” CMU/SEI-2007-TR-009 (Software Engineering Institute, Carnegie Mellon Univ., Pittsburgh, May 2007).
R. Curts and J. Frizzell, “Implementing Network-Centric Command and Control,” 10th International Command and Control Research and Technology Symposium (McLean, VA, 2005).
Department of Defense Science and Technology Priorities for FY 2013–2017 Planning (2011); http://ctovision.com/wp-content/uploads/2011/05/sNtpriorities.pdf (as of Dec. 7, 2011).
Department of Defense Space Science and Technology Strategy 2011, Prepared by ASD (R&E), Response to Congress, Sect. 2272, Title 10, USC Space Science and Technology Strategy as Amended by NDAA 2010 Sect. 911 (2011).
Department of Defense Strategy for Operating In Cyberspace; http://www.defense.gov/news/d20110714cyber.pdf (as of Dec. 7, 2011).
A. Dwivedi, D. Tebben, and P. Harshavardhana, “Characterizing Cyber-Resiliency” MILCOM (San Jose, CA, 2010).
X. Fan, J. Yen, and R. Volz, “A Theoretical Framework on Proactive Information Exchange in Agent Teamwork,” AI Journal, Vol. 169, No. 1, pp. 23–97 (2005).
D. Hathaway, The Digital Kasserine Pass: The Battle Over Command and Control of DoD’s Cyber Forces (The Brookings Institute, Washington, DC, 2011).
N. Howes, Distributed System Architecture and Specification (IEEE, 2010).
N. Howes, M. Mezzino, and J. Sarkesain, “On Cyber Warfare Command and Control Systems,” 9th International IEEE Command and Control Research Technology Symposium (Copenhagen, 2004).
R. Knight, “An Operational Framework for Battle in Network Space,” 10th International Command and Control Research and Technology Symposium (McLean, VA, 2005).
E. Lee, “Cyber Physical Systems: Design Challenges,” Technical Report No. UCB/EECS-2008-8 (University of California, Berkeley, 2008).
M. Mezzino, DEACF User Manual (Cyber Soft Solutions, LLC, 2010).
National Space Policy (June 28, 2010); www.whitehouse.gov/sites/default/files/national_space_policy_6-28-10.pdf (as of Dec. 7, 2011).
J. Salerno, “Measuring Situational Assessment Performance Through the Activities of Interest Score,” 11th International Conference on Information Fusion (IEEE, 2008).
J. Salerno, G. Tadda, D. Boulware, M. Hinman, and S. Gordon, “Achieving Situational Awareness in a Cyber Environment,” Proceedings of Situation Management Workshop of MILCOM (IEEE, 2005).
G. Tadda, “Measuring the Performance of Situational Awareness Systems,” 11th International Conference on Information Fusion (IEEE, 2008).
G. Tadda et al., “Realizing Situational Awareness in a Cyber Environment,” Multisensor, Multisource Information Fusion: Architecture, Algorithms, and Applications (SPIE, 2006).
Back to the Spring 2012 Table of Contents
Go to sidebar: Cybersecurity Testbeds at The Aerospace Corporation
Go to sidebar: Toward Space Cyber Integration