Push is on for secure operating systems

The need for a secure operating system is often associated with government projects for the Department of Defense, the National Security Agency (NSA) or other agencies with sensitive information related to national security. Embedded software used in such products must have the entire system evaluated for security. That system evaluation, however, is extremely costly. As a result, in many instances the operating system is allowed to run and work in concert with other systems in what is referred to as "system high mode," where security and information-assurance responsibility are offloaded across several OSes to create a high-security environment.

Companies in the private sector are starting to be held to the same security standards as U.S. government agencies. For example, Internet service providers, financial institutions and power companies are being forced to evaluate OSes and products that are part of the country's critical security infrastructure. Recent virus attacks have demonstrated that there is a significant need for secure OSes that cannot be hacked or compromised. Security breaches cost hundreds of millions, if not billions, of dollars. With the formation of the Department of Homeland Security, it will not be long before regulations are put in place mandating that companies evaluate the security level of their embedded-software products for system integrity, to ensure that security cannot be compromised.

Levels of security
This article will discuss the issues related to the security of today's operating systems, the need for Common Criteria EAL-7 operating systems and the technical challenges and solutions involved in providing a high-level design for secure OSes that can be built and evaluated to the highest assurance levels.

Why has no one built a secure OS? The answer depends on the level of security needed. Currently, developers outside the government sector adhere to the Common Criteria specification to define the level of security for their products. Common Criteria defines seven Evaluated Assurance Levels (EALs), with 1 being the lowest level and 7 the highest. While Common Criteria does not require their use, EALs are generally accepted as the best means for defining the security level of OSes. EAL-7 is equivalent to security level A in the Defense Department's Orange Book, the highest level of security for government systems.

The Pentagon has spent up to half a billion dollars sponsoring numerous failed attempts to provide a generic, readily available, secure OS that can be evaluated to the highest assurance levels used by the government. The NSA gathered 20 experts to examine each of those efforts and concluded that each OS encountered the same problem: It became overutilized in addressing various security concerns. As a result, each OS was too large; it became mathematically impossible to evaluate the design of the OS, breaking one of the four basic tenets that have been identified to assure a secure operating system.

The NSA experts also concluded that part of the responsibility for security lies with the applications. If a secure operating system is not available, however, it becomes impossible to achieve a secure application.

To facilitate the building and evaluation of a secure OS, the NSA examined the paradigm of a separation kernel. The kernel was designed to be certified to EAL-7 and to meet each of the four tenets that assure a secure OS: evaluatable, nonbypassable, always invoked and tamper-proof.

The separation kernel executes in system mode, provides time and space partitioning and restricts the kernel to only two main functions: information flow and data isolation. Information flow sets restrictions on when applications are allowed to communicate, and data isolation ensures that data cannot intentionally or accidentally infiltrate an application. If the kernel is limited to those two functions, it will remain relatively small. Given the small amount of code in the kernel, the four tenets are achievable, and a secure operating system can be built.

Additional kernel activities are then moved to the application space. Since applications must always use the kernel when communicating outside their own partition, the security policies are "always invoked" and are "nonbypassable."

Because the security policies are at the highest security level in the system, it is possible for the system to support applications of mixed security levels and to allow or deny communication between differing levels of security. This is referred to as multilevel security (MLS).

The Defense Department has recognized and mandated the need for MLS in its future systems. For example, MLS will allow soldiers in the field to use systems that are capable of running very sensitive information and ensure that this same data is not accidentally shared with personnel who are not authorized to view it. That eliminates the need for all the embedded computers in a system to run on system high. The aviation industry currently recognizes some of these concepts in DO-178B Level A systems.

Secure RTOS and DO-178B
DO-178B is a standard used by the Federal Aviation Administration to certify systems for flight. There are five levels, ranging from E to A, depending on how the system is affected in case of failure. For example, Level E states that no safety issues exist. Level A systems refer to catastrophic failure that will more than likely result in loss of life and aircraft. Level A systems typically include flight controls, engine controls and primary flight displays.

The University of Idaho in 2001 and 2002 performed a study comparing DO-178B with Common Criteria and concluded that software developed to DO-178B Level A standards maps closely to EAL-4-or, in some cases, EAL-5-with some additional work. This additional work is mandatory to satisfy objectives not covered by DO-178B. But good engineering practices, such as delivery mechanisms and vulnerability assessments, may satisfy those requirements.

A DO-178B kernel's space partitioning generally will solve most of the problems related to information flow, since there is no sharing of memory among partitions. This is done to protect partitions from one another. In addition, the time partitioning used in DO-178B kernels will prevent a single partition from monopolizing system resources, which often causes system security concerns. Those two features alone meet most of the requirements of a secure kernel.

Levels EAL-5, EAL-6 and EAL-7 require additional work, all of which can be done in the required semiformal and formal design analysis. Additional software development will be mostly in the area of information flow among partitions to ensure that data is isolated at the same time.

Currently, there is no OS that is certifiable to level EAL-7. Consensus among the NSA and the embedded-OS industry is that most of the work will be in formal methods necessary to achieve an EAL-7 rating, provided that the kernel is kept small and only provides the minimal functionality needed to support information flow and data isolation. If users have at their disposal a DO-178B Level A-certifiable system, most of the work for a high-assurance OS is already done.

Several DO-178B Level A-certifiable real-time operating systems exist, including LynuxWorks' LynxOS-178. Certified by the FAA, LynxOS-178 is a Posix-conformant OS that includes Rockwell Collins' VMOS intellectual property to execute in system mode and access hardware directly. With the addition of a separation kernel, LynxOS-178 has demonstrated EAL-7 functionality. Currently, LynxOS-178 can be easily certified to the Common Criteria EAL-4, and LynuxWorks is building on that technology to be able to deliver an RTOS certifiable to the Common Criteria EAL-7.

Arun Subbarao is director of software engineering at LynuxWorks Inc. (San Jose, Calif.).

See related chart