Holding the High Ground: Defending Satellites From Cyber Attack
The Cyber Edge Writing Contest 1st-Place Winner, 2023
MIT Lincoln Laboratory and the Space Cyber-Resiliency group at Air Force Research Laboratory-Space Vehicles Directorate have prototyped a practical, operationally capable and secure-by-design spaceflight software platform called Cyber-Hardened Satellite Software (CHSS) for building space mission applications with security, recoverability and performance as first-class system design priorities. Following a successful evaluation of CHSS against an existing U.S. Space Force (USSF) mission, the CHSS platform is currently being extended to support hybrid space vehicle architectures that incorporate both CHSS-aware and legacy subsystems. CHSS has the potential to revolutionize the cyber-resiliency of space systems and substantially ease the burden of defensive cyber operations (DCO).
DCO on space systems has historically ranged from intractable to impossible due to the inherent constraints of the domain. Not only are satellites physically inaccessible, with bandwidth-constrained and intermittent communication links, but cyber-physical safety constraints impose strict timing and predictability requirements that few existing DCO tools could meet. Moreover, the importance of space heritage results in mission-critical code with strong resistance to modernization. A satellite is an integrated system of opaque software and hardware components with complex and diverse provenance. Without the ability to inspect or command these components, DCO tools are often relegated to best-effort monitoring of the communications bus. The combined challenge is akin to defenders being asked to defend a tank that lacks armor and whose crew is actively opposed to the idea. The attacker has every advantage.
One might incorrectly believe that satellite software is a difficult cyber target. Unfortunately, that’s not the case. MIT Lincoln Laboratory researchers analyzed common spaceflight software inventories and identified major concerns with widely deployed operating systems, third-party software dependencies and firmware that allow adversaries to implant automated malware via software supply chain attacks during satellite development or integration. Furthermore, software supply chain attacks are just one of many possible cyber threat vectors. For example, the increasingly networked world of cross-linked constellations offers another avenue for attackers to leverage one compromised satellite to attack others.
This hostile environment requires a revolutionary approach to defensive cyber operations to regain the advantage and deny attackers access to critical space systems.
Revolutionizing DCO: To tackle this problem, MIT Lincoln Laboratory researchers distilled the challenges outlined above into four adversarial conditions that spaceflight software must tolerate during operation. That is, the only way for spaceflight software to be resilient to cyber attack by nation-state actors is to function despite these conditions:
- A cyber attack has already succeeded. One or more flight software components are compromised. DCO personnel do not know which one in advance or the end goal of the malware. This is consistent with software supply chain attacks that go undetected until malware activation.
- Humans are unavailable at the necessary timescales. Malware operates at the speed of computation. A human operator cannot respond in real time, especially given that ground segment links are often intermittent and bandwidth-limited.
- Safety violations are worse than security violations. Violation of cyber-physical requirements can damage or destroy the satellite. If DCO software causes safety violations, it imposes an unacceptable risk to the mission system.
- Uncooperative software will always be present. Proprietary software, unmodifiable space heritage software, software built for specific operating systems, binary-only software or software from stakeholders that do not value cyber-resiliency is unavoidable. There are too many subsystems and different units of integration to avoid opaque components that must be trusted but cannot be proven as trustworthy.
These conditions effectively act as security design requirements for spaceflight software that, when satisfied, result in a revolutionary DCO capability to return the advantage to the defender. Such spaceflight software could operate through cyber attacks that have already established a foothold, mitigate the attack at least semiautonomously, meet cyber-physical timing requirements, integrate with existing spaceflight software and avoid removing existing flight heritage or imposing unrealistic requirements on stakeholders.0
CHSS is a promising starting point for realizing this ambitious vision. CHSS is a mission-agnostic spaceflight software platform whose functionality was inspired by NASA’s core Flight System but with an emphasis on cyber-resiliency. Most notably, CHSS offers security without sacrificing performance.
At its core, CHSS builds on the seL4 microkernel as a secure foundation and root of trust. seL4 is formally verified, which is a powerful but labor-intensive process to mathematically prove the absence of bugs and the correctness of a software implementation. For this reason, seL4 has previously been used on the Defense Advanced Research Projects Agency High Assurance Cyber Military Systems and Air Force Research Laboratory Amateur Radio Emergency Service programs. However, as a microkernel, seL4 alone offers only limited system functionality.
As a major step up from the basic functionality of seL4, CHSS implements a feature-rich set of operating system services, a security-mediated software data bus for cross-application communication, autonomous recovery mechanisms and modular flight software applications that support operating through and remediating cyber attack.
As elaborated, CHSS’ design and prototype currently satisfy the first three adversarial conditions and are currently being extended to support containerization and transparent protection of legacy spaceflight components to satisfy the fourth requirement.
To limit the harm of a compromised dependency, driver or a future application, CHSS is carefully architected using the core cybersecurity principles of functional isolation and least privilege (akin to zero trust). Furthermore, CHSS is implemented in the memory-safe Rust language, which is one of the languages recommended by the National Security Agency for secure system implementation.
Functional isolation limits cross-application interactions to the pre-approved communication channels. Software in CHSS is decomposed into discrete modules with well-defined inputs and outputs. Each module is given its own dedicated resources and memory domain at system start. The only way for modules to communicate with one another is through a software data bus that enforces a security policy on messages. This approach simultaneously isolates malicious code to its original module and encourages the reuse of modules across different missions.
Least privilege is a design principle in which every system component must only receive access to the resources it needs to perform its legitimate purpose and no more. Inspired by this principle, CHSS distributes capabilities, or unforgeable tokens, to processes that allow access to specific system resources (e.g., memory pages). Much like a traveler without a valid plane ticket, a process without a capability cannot access the associated system resource. Because seL4 manages capabilities for CHSS, their security derives from the formally verified correctness of seL4.
In CHSS, since human DCO operators are assumed to be unavailable at the necessary timescales to mitigate an ongoing cyber attack, malicious behavior and non-malicious faults trigger a phased autonomous recovery process. This process begins with module-level restarts, escalates to flight software and full-system reboots and culminates with fallback to a known safe state. Triggers include both explicit policy violations and failures to periodically alert a recovery handler that a module is in a good state. Normally, this kind of fine-grained recovery risks the desynchronization of flight software modules due to stale data, missed requests, etc., but CHSS explicitly designs applications with recovery in mind. Specifically, communication is stateless, and the recovery period is fast enough to avoid any safety violations in the cyber-physical regime.
While module restarts are sufficient to recover from transitory faults (e.g., memory corruption), they cannot contend with malware baked into the binary (e.g., a software supply chain attack). When CHSS detects that an application is repeatedly faulting, it can be configured to reboot into a “safe mode” from a separate boot image with a much smaller, simpler and more highly assured software suite. This boot image contains no code from the main image and is limited to maintaining safety-of-flight and receiving updates from the ground segment. This stops extant malware and grants groundside DCO personnel the time needed to develop and upload an update that removes the malicious code.
However, cyber-resiliency is only valuable if it does not come at the cost of safety violations. To demonstrate cyber-physical compatibility, MIT Lincoln Laboratory researchers evaluated CHSS against an existing USSF space domain awareness mission. The mission flight software to control the satellite bus was ported to CHSS. A processor-in-the-loop testbed was built that uses a hardware flight computer and software emulations of bus hardware peripherals—for example, reaction wheels and star trackers. Closed-loop astrodynamics simulators provided inputs to the flight software from emulated hardware sensors, processed actuation commands from the CHSS flight software and adjusted the orbital environment model appropriately. This allowed CHSS to fly a virtual satellite with realistic cyber-physical properties generated from astrodynamics simulations. Under this experimental scenario, the CHSS flight software successfully operated the emulated satellite bus peripherals, ensured the absence of safety violations, maintained performance comparable to non-hardened operating systems used on satellites today, such as real-time Linux, and easily met soft real-time requirements for cyber-physical operations, such as attitude sensing/actuation control loops.
CHSS is a secure-by-design prototype that establishes the potential of spaceflight software that is simultaneously performant, cyber-resilient, practical and able to shift the advantage from attackers to DCO operators. CHSS’ modular framework is designed to integrate well with future applications focused on payload operations, communications stacks and other important space systems software. In addition, our vision embraces the reality of uncooperative, legacy software components always being present in satellite systems. The CHSS platform is currently being extended to support the wrapping and containerizing of such legacy software to provide cyber-resiliency without breaking space heritage or making unreasonable demands of stakeholders.
Evolving the CHSS platform to establish it as a mature reference standard for future space systems can be a DCO game-changer in space.
Dr. Richard W. Skowyra is a technical staff member in the MIT Lincoln Laboratory Secure Resilient Systems and Technology (SRST) group. Skowyra currently leads the group’s efforts in designing cyber-resilient satellite systems. He also works with partners inside and outside the laboratory to ensure that next-generation national security capabilities are simultaneously performant and resilient to cyber attack.
Samuel A. Mergendahl is an associate staff member in the MIT Lincoln Laboratory SRST group, where he works on secure system engineering. Mergendahl believes performance and security can gracefully coexist in the design of even low-level, embedded system software. Mergendahl’s work leverages advances in programming languages, such as Rust, to ensure functional and cyber assurance of critical mission systems.
Dr. Roger Khazan is the leader of the MIT Lincoln Laboratory SRST group, where he leads a team of talented researchers and engineers in helping the laboratory’s sponsors and partners solve some of the hardest technical problems relevant to national security. Khazan is passionate about creating and transitioning to practice cutting-edge cybersecurity solutions for mission-critical systems—solutions that are efficient, affordable, easy to integrate and easy to operate.
Acknowledgments and DoD POC: Joseph “Dan” Trujillo, Space Cyber Resiliency Lead DR-3, Space Force/Air Force Research Labs/Space Vehicles. We would also like to thank all the Lincoln Laboratory team members who have contributed to CHSS and related efforts (J. Furgala, R. Govotski, S. Jero, D. Kava, D. Langus Rodriguez, B. Nahill, E. Simpson).
DISTRIBUTION STATEMENT A. Approved for public release. Distribution is unlimited. This material is based upon work supported by the Department of the Air Force under Air Force Contract No. FA8702-15-D-0001. Any opinions, findings, conclusions or recommendations expressed in this material are those of the author(s) and do not necessarily reflect the views of the Department of the Air Force.
