White Paper

WHITE PAPER RelianceOne: Guidelines for Securing Combat Systems mrcy.com 2 mrcy.com 2 Cyber-attacks against mission-critical combat systems are a growing concern across the Department of Defense. Existing approaches to securing and defending these systems almost universally adopt methods used to protect enterprise systems such as: basic network firewalls, persistent threat monitoring and auditing. These solutions most often do not anticipate the real-time requirements, operational remoteness, and resource constraints often associated with combat systems. INTRODUCTION Combat systems differ from enterprise systems in several other ways as well. First, combat systems overwhelmingly rely on the Linux or other non- Windows operating systems. Enterprise networks, on the other hand, are predominately comprised of Microsoft Windows hosts. Second, the number of authorized users is significantly smaller. Enterprise networks for large businesses or organizations have thousands of users; combat system users, i.e., individuals requiring a username / password, on the other hand, range in the dozens if they have users at all. This number shrinks further when one considers the requirements for concurrent users, i.e., individuals using the system at the same time. Next, the behaviors of combat systems can be characterized as less random. This, of course, being a function of the small number of users and the overall purpose of the system. Fourth, combat systems, large and small, have the risk of being lost to the enemy during overseas operations or in battle. As a result, system designers cannot approach security with only a remote attacker in mind. Instead, security must include technology protection and anti-tamper solutions. Taking these differences into account, designers of a security solution for combat systems should consider solutions that follow the guidelines below. Use What is Available Combat system security is often improved by adding proprietary security software. These solutions implement security and anti-tamper by modifying important system calls (a technique often referred to as hooking). This approach significantly increases the cost of maintenance, testing, and integration as it effectively changes the Linux kernel in unanticipated ways—ways the Linux open source community is unable to support long-term. As a result, these products require revision with the release of every new Linux release. In contrast to this approach, there exist several frameworks and auditing components supported by the Linux open source community that can be leveraged for a variety of security purposes, e.g., monitoring, data protection, etc. These components, such as Linux Security Modules (LSMs), auditd, and overlay file systems can all aid in enhancing the security of combat systems. Eliminate and De-Privilege Users The majority of user accounts on combat systems are often used for testing and configuration prior to fielding. These accounts can be removed prior to installation / deployment. The root or administrator account can also be de-privileged to de-incentivize privilege escalation attacks. Privilege escalation attacks pose a significant security risks to both combat systems and enterprise systems. These attacks take place once an intruder gains an initial foothold on a target system. Their purpose is to obtain privileges equal to the privileges of the root or administrator account in order to establish persistent access, collect intelligence, or to cause an effect. This is often accomplished by exploiting a bug, design flaw, or configuration oversight in an operating system or application. De-privileging the root / administrator account means an intruder cannot use the elevated privileges given to the root / administrator account to bypassstandard discretionary access controls. Effectively, an intruder whosuccessfully executes a privilege escalation attack will not be allowed to delete other users' files, view sensitive information, or deploy malware with system-level access. Employ Mandatory Access Controls Discretionary access controls, however, are limited. They give users the power to set the access controls for their files. Unfortunately, it is more likely that users will set overly permissive controls on their files – something that weakens the overall security of the system. Additionally, discretionary access controls are not fine grained enough to provide for more complicated control scenarios. While this may be necessary in enterprise environments, combat systems often do not require this flexibility. Mandatory access controls, in contrast to discretionary access controls, give control of file access to the operating system, overriding any users controls. This means a malicious or compromised process running as an authorized user with permissions to access a resource or modify a configuration file, can still be denied access. This is particularly important and achievable with combat systems since malicious or compromised processes are a greater threat than users.

• Cover