Palm Harbor, FL. – A Zero Trust security posture assumes every user and device is untrusted, even if it is located within the protected perimeter of the local network. The Zero Trust Maturity Model version 2.0 from the Cybersecurity and Infrastructure Security Agency (CISA) defines 30 high-level functions to be implemented, but many of those do not apply to military avionics systems and other deeply embedded system.

For example, military avionics systems have no users, so there is no need for multi-factor authentication, biometric scans, user behavior analytics, or role-based access control (RBAC). (Pilots and crew are not considered “users” in the traditional sense because they do not log in and they provide only limited input to pre-programmed applications.) Military avionics systems also have no open network ports (e.g. web browsing, email, remote access) and no daemons (e.g. DNS, printer, routing, network manager) unless the system architect explicitly configures them. In fact, avionics systems at high design assurance levels, such as DO-178C DAL A/B/C, should have no background applications running at all in order to ensure that the application that is supposed to be running on each processor core gets all the resources it requires in a deterministic manner. Real-time operating systems (RTOSs) can use those constraints to provide the foundation for a zero-trust architecture with lower overhead, smaller footprint, and higher security.

Stable system configuration

Aside from having no users, the most important property of avionics systems is a stable set of subjects (applications), devices (embedded processors), and communication paths. Adding new applications or devices is rare, and even upgrading applications or devices happens infrequently. The result is that the system integrator locks down the system configuration, not just the operating system but also the middleware and applications. Scheduling of trusted application execution and approved communication paths (data flows) can be defined statically in a configuration file used at boot time. Using only predefined configurations improves determinism, safety, and security. The INTEGRITY-178® tuMP™ RTOS from Green Hills Software, for example, supports this with a static configuration file that lists all the approved applications, assigns those to partitions, and lists all the approved communication between those partitions. Those applications, assignments and communication paths cannot be changed or modified during execution, but multiple static configurations can be defined in the configuration file.

Many avionics systems can benefit from the availability of multiple static configurations. During runtime, systems can choose between the pre-approved configurations to adapt to a component failure or a change in operational mode. This functionality is defined in ARINC 653 Part 2 “Multiple Module Schedules.” The INTEGRITY-178 tuMP RTOS provides Multiple Module Schedules functionality both as an ARINC 653-compliant solution and as a native feature of the RTOS called Mode Change capability. Note that anytime a runtime configuration change is invoked, the security functions have the additional requirement to continuously maintain a secure state before, during, and after the configuration change.

Zero Trust principles

A Zero Trust Architecture moves away from the default policy of “trust but verify” for entities inside a perimeter defense to a policy of “never trust, always verify” for all entities. Every user, device, application, and data flow is verified, whether inside or outside a traditional network boundary. The other core concept of Zero Trust is the principle of least privilege to be applied for every access decision. Common to many security approaches, the principle of least privilege calls for a subject to be given only the minimum access level required to perform a given task.

The DoD Zero Trust Reference Architecture, Version 2.0, defines five major tenets:

1. Assume a Hostile Environment.
   There are malicious personas both inside and outside the environment. All users, devices, applications, environments, and all other Non-Person Entities (NPEs) are treated as untrusted.
2. Presume Breach.
   Consciously operate and defend resources with the assumption that an adversary has presence within your environment. Enhanced scrutiny of access and authorization decisions to improve response outcomes.
3. Never Trust, Always Verify.
   Deny access by default. Every device, user, application/workload, and data flow are authenticated and explicitly authorized using least privilege, multiple attributes, and dynamic cybersecurity policies.
4. Scrutinize Explicitly.
   All resources are consistently accessed in a secure manner using multiple attributes (dynamic and static) to derive confidence levels for contextual access to resources.
5. Apply Unified Analytics.
   Apply unified analytics for Data, Applications, Assets, and Services (DAAS) to include behavioristics, and log each transaction.

Separation kernels for embedded security

A well-accepted foundation for military embedded security is the use of partitioning to run applications in separate, isolated partitions. Apart from microcontrollers and digital signal processors, most CPU chips used in embedded systems include a memory management unit (MMU) that can be used for hardware-enforced partitioning of memory for different applications. Although that MMU can be controlled by a general-purpose OS or an industrial RTOS, the most secure systems use a separation kernel. A separation kernel is a specific type of microkernel where the essential functions running in privileged kernel mode are only the most critical security functions.

A separation kernel is a minimized OS kernel whose only function is to enforce four basic security policies: data isolation, fault isolation, control of information flow, and resource sanitization.  All other OS services are moved to user space so that the code size and attack surface of kernel code is the absolute minimum. One way to think of this is to apply the principle of least privilege to the OS itself. Software components with the largest attack surfaces and the most vulnerabilities, such as the networking stack, file system, and even virtualization, can execute sufficiently in user mode, so the security policy should not allow them to execute in privileged kernel mode. That is exactly what the INTEGRITY-178 tuMP RTOS does: OS services and an optional virtualization layer execute in user space on top of a secure separation kernel.

A less secure alternative to a separation kernel is a Type 1 (bare metal) hypervisor, which provides virtualization in addition to isolation.  The virtualization code is implemented in the kernel to increase virtualization performance at the expense of a larger kernel attack surface. Virtualization only enables running different operating systems and does nothing to increase security. To the contrary, that more extensive complex code base is much harder to secure, let alone prove it is secure.

Mapping separation kernel attributes to Zero Trust principles

The fundamental security policies enforced by a separation kernel – data isolation, fault isolation, control of information flow, and resource sanitization – map well to Zero Trust principles. Layered security extensions in the OS services provide additional capabilities.

The bottom line: military avionics requires only a subset of the overall zero trust functions, and pure separation kernels like the INTEGRITY-178 tuMP RTOS can provide a strong foundation of a Zero Trust Architecture for those systems. For programs that require more security than Zero Trust, the INTEGRITY-178 tuMP RTOS has been used as the foundation for a tactical cross domain solution (CDS) that has been used to meet NSA’s “Raise the Bar” set of cross domain security requirements. Ever since it was first deployed over 20 years ago, the INTEGRITY-178 family of operating systems has never had a single vulnerability reported.