White Paper

WHITE PAPER RelianceOne: Guidelines for Securing Combat Systems mrcy.com 3 The Mercury Systems logo is a registered trademark of Mercury Systems, Inc. Other marks used herein may be trademarks or registered trademarks of their respective holders. Mercury products identified in this document conform with the specifications and standards described herein. Conformance to any such standards is based solely on Mercury 's internal processes and methods. The information contained in this document is subject to change at any time without notice. The appearance of U.S. Department of Defense (DoD) visual information does not imply or constitute DoD endorsement. © 2025 Mercury Systems, Inc. 8216.00E-1024-wp-relianceone-guidelines Corporate Headquarters 50 Minuteman Road Andover, MA 01810 USA +1 978.967.1401 tel +1 866.627.6951 tel +1 978.256.3599 fax International Headquarters Mercury International Avenue Eugène-Lance, 38 PO Box 584 CH-1212 Grand-Lancy 1 Geneva, Switzerland +41 22 884 51 00 tel MADE IN USA Learn more Contact: mrcy.com/contactus Embed Anti-Tamper Protections As was previously mentioned, combat systems are unique in that they come in close contact with adversaries. Sometimes this contact takes place during battlefield operations, but it can also take place through foreign intelligence operations or the inadvertent misplacing of smaller systems like lost mobile devices. One of the most well-known examples of this close contact is the 2001 China-US Aircraft Collision Incident. In April of 2001, a U.S. Navy EP-3E (a signals intelligence aircraft) made an emergency landing in China's Hainan province after colliding with a Chinese fighter aircraft. After the EP-3E landed the crew was detained and the Chinese thoroughly stripped and examined (reverse engineered) the aircraft 's equipment. While the disassembled aircraft was eventually returned, the event highlights the need for combat systems to use antitamper technologies to protect hardware and software. Software protections range in capability and intrusiveness. Sound approaches to software protection include just-in-time encryption/decryption of binaries, disabling debugging, and proper key management. Other important elements of a good software protection plan include minimizing or encrypting logging, denying core dumps, and limiting the use of untrusted memory. MERCURY'S RELIANCEONE SECURITY SUITE FOR LINUX Mercury 's RelianceOne Security Suite for Linux follows the above guidelines while also addressing 100% of technical RMF security controls. RelianceOne leverages several Linux- provided security components and supports both standard (i.e. RedHat, CentOS, Ubuntu, and Red Hawk) and vendorspecific Linux distributions for Intel and ARM, including Wind River Linux and other Yocto-based Linux distributions. Additionally, RelianceOne ensures that even privileged users (or processes) cannot interact with or access the memory contents of a protected application. The mandatory access controls implemented within RelianceOne deprivilege the root / administrator user, ensuring that combat systems can be configured and deployed as single-purpose systems. Additional controls to protect access to applications, data, and configuration files are also easily defined using RelianceOne's feature-rich tooling. Finally, RelianceOne keeps applications, libraries, and data encrypted at rest. RelianceOne employs just-in-time decryption to verify and decrypt applications, libraries, and data before they are executed or accessed. This ensures applications or libraries that have been modified will be prevented from being executed. RelianceOne also prevents debuggers from accessing applications, memory segments, and libraries. RelianceOne even keeps adversaries from copying or removing protected applications from the system.

• Cover