Microprocessor-based defence subsystems are traditionally built using multiple embedded boards, each running a single application or component that together delivers the functionality required by the subsystem. But this traditional approach no longer scales, and a RTOS architecture and system infrastructure - Multiple Independent Levels of Security - has emerged to meet the new challenges, wites Robert E. Hoffman.
Modern defence system demands
In the face of modern threats, national defence requires ever more lethality and survivability in new environments. Defence planners must also meet purchase and operational cost targets. For the defence system builder, this translates to increasing requirements for more device functionality, mobility, connectivity, security and safety, with lower purchase and operational costs and controlled development time, cost and risk.
Demand for more connectivity to support integrated battle spaces is especially intense where devices connect to the United States Global Information Grid (GIG) or similar schemes elsewhere. This connectivity, coupled with the need to share information among coalition partners with varying degrees of trust, makes security requirements difficult to meet.
Microprocessor-based defence subsystems are traditionally built using multiple embedded boards, each running a single application or component that together delivers the functionality required by the subsystem. The traditional approach to delivering more functionality is to increase the number of subsystems and boards.
This traditional approach no longer scales. In addition to the requirements given above, space, weight and power (SWaP) are ever more constrained in modern defence systems. From unmanned combat air systems to highly mobile tactical operations centres and modern attack aircraft, there is continued pressure to reduce subsystem form factors to accommodate more arms and armour.
Multiple applications on a single processor
Fortunately, modern microprocessors are rising to the challenge and faster multicore processors in particular are emerging as compelling technology.
To take advantage of more powerful microprocessors, the major commercial real-time operating system (RTOS) companies are developing approaches to enable multiple applications to share a single microprocessor, thereby reducing the number of embedded boards in a subsystem and potentially the number of subsystems.
Running multiple applications on a single microprocessor introduces major new challenges. First, every application must be guaranteed processor time, memory, bandwidth and any other resources it requires. No application can be allowed to starve others of their required resources.
Second, applications formerly made secure by "air-gap security" must remain secure, limiting and minimizing damage from malicious attacks, and must communicate exactly as intended and in no other way. While malicious covert channels are possible on traditional systems, hosting several applications on a single microprocessor introduces new potential exposures.
Safety and security evaluation present a third challenge. defence systems are Authorized to Operate (ATO) by Designated Approving Authorities in the United States and similar authorities elsewhere. Historically, "large" systems - with hundreds of thousands to millions of lines of code - have been difficult to certify.
Figure 1: Traditional Secure System Architecture
As illustrated in Figure 1 above, this is because such systems have typically been designed with large, relatively monolithic kernels that manage resource allocation, mandatory and discretionary access control, security auditing and event recording and more, with drivers all running in "privileged" or "supervisor" mode.
Further, the systems include relatively large and monolithic middleware, such as network stacks, file systems and large applications. With security-critical code not well isolated in the large code bases, security evaluations have been complex and expensive (as high as $50-$100 million).
In addition to security evaluations, a growing challenge for unmanned aircraft, especially in Europe with its narrow military air corridors, is a trend to require safety certification that formerly was required primarily for commercial aircraft.
Controlling operational cost is a fourth challenge. The simple approach with applications on a single processor is to operate in "system high" mode. But this requires all personnel with access to the system to be classified at the highest level, often Top Secret, which is expensive and increasingly impractical.
Finally, the increasing functionality required of these complex systems increases the amount of software, which in turn increases the time, cost and risk of developing and integrating these systems. These costs must be controlled throughout a system life cycle that may span several decades.
Summarising the challenges, running multiple applications on a single multiprocessor (whether single-core or multicore) is compelling for increasing functionality while controlling SWaP, but doing so creates new threats of interference in applications, security, evaluating and certifying safe and secure system operation, potentially increased operating personnel cost and more challenging development.
The rise of MILS
A RTOS architecture and system infrastructure has emerged to meet these challenges called Multiple Independent Levels of Security (MILS).
MILS uses a strategy of "divide and conquer" to carefully and rigorously isolate multiple software components running on a single microprocessor to guarantee the required resources to each component, enabling separate development, safety and security evaluation for each independent component and providing for composition of components into a single system that delivers the total functionality required.
Divide and conquer
The MILS divide and conquer approach has three themes:
• Separation: The software for the system is partitioned into components. Different applications, middleware and driver components can be readily separated. Individual applications, middleware and drivers may be further subdivided. The goal of separation is to isolate security-critical code in small components so that all security-critical code can be scrutinized intensely. Code of lesser or no security-criticality can be evaluated at lower levels or not at all.
• Composition: The complete software for a system is built by composing the evaluated components to implement the overall functionality for the system - that is, by executing them together on the system in a way that ensures each component has the resources it requires, that the components communicate exactly as specified, and that no component can affect any other component other than as specified by system security policies (i.e., there are no covert channels).
• Layered assurance: Instead of placing all responsibility for security in the kernel, the responsibility is distributed among the Separation Kernel and all user components, with each component responsible for its own security policy.
Three-layer MILS architecture
While there are several approaches to the MILS RTOS architecture, most broadly follow the three-layer scheme illustrated in Figure 2 below : trusted hardware, Separation Kernel, and user components (applications, middleware and drivers).
Figure 2: MILS System Architecture
Trusted hardware: There must be no intentional or unintentional exploits or covert channels present in the hardware that might defeat the security requirements. The hardware must also support trusted initialization to ensure the code running on the system is the same code certified by authorities. The details of trusted hardware are beyond the scope of this discussion; please consult commercial MILS RTOS vendors for more information.
Separation Kernel (SK): The SK has four responsibilities:
• Data and code isolation: prevention of unintended data and code commingling is accomplished through memory management for space partitioning.
• Periods processing: components are each assigned variable-length time slots in a fixed schedule, guaranteeing their time resources.
• Information flow control: information originates only from authorized sources, is delivered only to the intended recipients and the source of information is authenticated to the recipient.
• Fault isolation: damage limitation is achieved by preventing a failure in one partition from cascading to others; failures are detected, contained and recovered locally.
By implementing the MILS Separation Kernel security policy, a MILS SK isolates the other software components of the system in a much more profound and demonstrable way than in the past with secure systems.
To achieve high security assurance, the SK is typically the only code to operate in privileged mode. All other software components, including drivers and middleware, run in user mode in separate space partitions.
User components - These are applications, middleware or drivers, each executing in its own space partition per the defined schedule.
A key advantage of MILS is the ability to run legacy code that may come from traditional RTOS environments, Linux or even Microsoft Windows. A MILS system permits legacy code to run by hosting their OSs in space partitions as "guest operating systems." Since the guest OSs and their hosted components are isolated in partitions, they may be evaluated, if necessary, to the appropriate level.
MILS systems are also designed to host applications requiring very high security assurance such as upgraders, downgraders, filters or other applications that must process data from multiple security domains. The expectation is that these applications are relatively small (roughly a few hundred lines), and because they can be isolated, they can be evaluated to very high security assurance. MILS vendors provide a "minimal runtime" to interface these high assurance applications to the SK.
Assurance of security
In general, we cannot achieve 100% assurance that a system is completely secure; however, using thorough evaluation methods, we can achieve an acceptable level of risk. For MILS-based systems, we need assurance that the underlying MILS operating system is secure. The major commercial RTOS vendors use the international Common Criteria for Information Security Technology Evaluation methodology (ISO/IEC 15408) principally because it is preferred in the US for demonstrating adequate information assurance for such software.
At its highest assurance levels, evaluations using Common Criteria are mathematically-based and expensive. Evaluation costs approximately $1,000 per effective line of code (SKs are typically in the 5,000-line range). In the United States, evaluation at the highest levels may require three or more years.
An entire operational system will not typically be certified using Common Criteria. In the US, a defence system is authorised to operate though DoD Information Assurance Certification and Accreditation Process (DIACAP). In addition, the intelligence community uses Director of Central Intelligence Directive 6/3 Protecting Sensitive Compartmented Information within Information Systems (DCID 6/3). Similar procedures are used elsewhere. In these processes, different types of evidence may be submitted for different subsystems. For example, DIACAP authorities accept Common Criteria certification and MILS RTOS vendors expect that their Common Criteria certifications currently under way will be acceptable.
MILS gets it done
MILS' ultimate goal is the development and certification of a library of reusable certified components - RTOS, drivers, middleware and applications - for composition into systems that can be evaluated and certified at acceptable cost.
MILS divides and conquers to help build today's Multi-Level Secure defence systems to process data at multiple security levels and from multiple coalition partners while increasing functionality and connectivity; reduce space, weight, power and purchase and operational cost; control development time, cost and risk; and slash the cost to demonstrate the safety and security of national defence systems.
Implementing MILS can be challenging, but the user is rewarded with Multi-Level Secure systems that meet today's and tomorrow's threats at reasonable cost and acceptable risk.
Robert E. Hoffman, Vice President and General Manager, Wind River Aerospace and Defence