Security Considerations for Embedded Operating Systems - Embedded.com

Security Considerations for Embedded Operating Systems

Security requirements, traditionally relegated to military aircraft andweapons, are now being promulgated into everyday embedded systems suchas automobiles, medical systems, radios, and household appliances. Theembedded operating system must satisfy specific assurance andfunctionality requirements in order to help achieve the highest levelsof security.

The increasing complexity of software controlling these systems, useof the internet, and risk of cyberterrorism are forcing embeddedsystems designers to rethink their software acquisition strategies tocope with this security challenge. The embedded operating system,because it controls the critical resources of the embedded computer,must satisfy specific assurance and functionality requirements in orderto help achieve the highest levels of security.

Common Criteria
Common Criteria is an internationally conceived and accepted standardfor performing security evaluations. Sponsoring nations include Canada,France, Germany, Netherlands, United Kingdom, and United States. Priorto Common Criteria, nations had independent, disparate methodologiesfor security evaluation; the U.S. DOD utilized the Trusted ComputerSystem Evaluation Criteria, known informally as the Orange Book.

The Orange Book calls out levels of increasing assurance andprotection via classes D through A, with subclass A1 being the moststringent. A major drawback of Orange Book was its lack of generality;Orange Book's focus on sensitivity labels, access controls, andauthentication made it applicable only to some classes of secureoperating systems.

On the other hand, typical “security kernels” would contain moresecurity features than may be needed by any particular system; suchsystems would nevertheless be forced to accept the associated largefootprint and assurance burden. The functional requirements were tooextensive to make it practical for a variety of commercial products toachieve the high assurance designated in the A1 subclass. Evaluationcriteria used in other nations suffered from similar problems.

Common Criteria uses a more flexible approach. Common Criteriaprovides a pool of security functional and assurance requirements fromwhich a specific profile, suitable for a specific type of product (suchas a real-time kernel, firewall, or file system) can be selected. Thefunctional requirements specify what security features the product musthave.

For example, a traffic-filter firewall profile may include therequirement that all attempts to change the security policies (e.g. thetraffic filtering rules) be recorded in an audit log for examination bysecurity personnel. The assurance requirements provide evaluators withthe confidence that the product satisfies the claimed functionalrequirements. These items may include high level and low level designdocuments, configuration management plans, covert channel analyses,testing plans and results, and proof of secure delivery to end users.

Common Criteria Evaluated AssuranceLevels (EAL)
In addition to the assurance artifacts, Common Criteria specifieslevels of assurance and applies these levels to each assurancecomponent. The increasing levels of assurance range from EAL1 to EAL7.The general meanings of the levels are shown in the following Table 1 below :

To understand how the assurance levels apply to the assurancerequirements families and components, let's look at an examplecomponent: ADV_HLD, “High-level Design”. According to Common Criteria,”The high-level design requirements are intended to provide assurancethat the TOE [target of evaluation] provides an architectureappropriate to implement the TOE security functional requirements.” Ifa Protection Profile includes this assurance requirement (most do),then the rigor of the requirement increases with assurance level, asshown in the Table 2 below:

The ADV_HLD component is further divided into elements which are theindividual descriptive requirements. With each increasing level,elements are added to the requirements inherited from the precedinglevel. For example, an EAL5 Protection Profile will include the elementADV_HLD.3.9C:

“Thehigh-level design shall describe the separation of the TOE into TSP[TOE Security Policy]-enforcing and other subsystems.”

Using our firewall example, this means that the high-level designmust point out the subsystems which enforce the traffic filteringrules. For an EAL6 Protection Profile, this requirement is augmented toADV_HLD.4.10C:

“Thehigh-level design shall justify that the identified means of achievingseparation, including any protection mechanisms, are sufficient toensure a clear and effective separation of TSP-enforcing fromnon-TSP-enforcing functions.”

In other words, evaluators will expect the vendor to providehigh-level design evidence that demonstrates that the traffic filteringsubsystems are protected from corruption, subversion, etc. by othersubsystems.

For an EAL7 Protection Profile, this requirement is furtheraugmented to ADV_HLD.5.10C which is the same as ADV_HLD.4.10C, exceptthat the presentation, or justification, must be formal: “A formal specification is written in anotation based upon well-established mathematical concepts.”

These mathematical concepts are used to define the syntax andsemantics of the notation and the proof rules that support logicalreasoning. The syntactic and semantic rules supporting a formalnotation should define how to recognize constructs unambiguously anddetermine their meaning. There needs to be evidence that it isimpossible to derive contradictions, and all rules supporting thenotation need to be defined or referenced.”

Why High Assurance?
Government security organizations, such as the U.S. National SecurityAgency, are of the opinion that high assurance is required to protectand control sensitive information and critical infrastructure. InDecember, 2003, the NSA published a letter concerning U.S. DODinformation technology certification and accreditation processes,stating:

“For systemsthat must maintain separation of information at different levels ofclassification, high assurance security design (specified by NSA or theInternational Common Criteria at a minimum Evaluated Assurance Levelgreater than 4)” is required.

According to Common Criteria (v2.1 Part 3: Security AssuranceRequirements, section 6.2.4): “EAL4is the highest level at which it is likely to be economically feasibleto retrofit to an existing product line.” Windows XP has beenevaluated at EAL4. At a recent technology conference, an NSA speakerwas asked what level of assurance consumers should expect from this.The speaker responded, with a smile, that “the operating system issecure as long as nothing is connected to it.”

As of this writing, there are no operating systems evaluated athigher than EAL5, although operating systems vendors are activelypursuing this. For example, Green Hills Software is under contract toobtain an EAL6+ (EAL6 augmented and extended with additionalrequirements) evaluation for its INTEGRITY real-time operating systemthat is used in high reliability applications including avionics,industrial control, medical systems, automotive telematics, andconsumer electronics (seehttp://niap.nist.gov/cc-scheme/in_evaluation#i). Other operating systemvendors have voiced their intent to pursue the same evaluation.

Security organizations are intent on levying high assurancerequirements (e.g. EAL6 or EAL7) in the civil sector wheneverappropriate. An example would be SCADA systems computer systems used tomonitor and control a plant or equipment in industries such as waterand waste control, energy, and oil refining. Many of these systems arerunning Microsoft Windows.

In 2000, a disgruntled ex-employee broke into a SCADA system andcaused millions of gallons of untreated sewage to be released.We can easily imagine other possible results if the perpetrator hadbeen a determined terrorist.

According to the Federal Technical Support Working Group (seehttp://www.tswg.gov/tswg/ip/SustainableSecurity.pdf), “The presentstate of security for SCADA is not commensurate with the threat orpotential consequences. The industry has generated a large base ofrelatively insecure systems, with chronic and pervasive vulnerabilitiesthat have been observed during security assessments. Arbitraryapplications of technology, informal security, and the fluidvulnerability environment lead to unacceptable risk.”

Clearly, better security is needed across a wide range of industriesand types of embedded systems. The separation kernel is the foundationof a new methodology intended to achieve this goal.

The Separation Kernel
The aforementioned EAL6+ evaluation efforts being pursued by operatingsystem vendors are targeting a Protection Profile known in the industryas the “Separation Kernel Protection Profile”. The separation kernelforms the foundation of a secure system by providing a fundamentalsecurity feature: separation (also known as partitioning).

A partition typically corresponds to a single user application(although it could correspond to more than one). The separation kernelenforces information flow policies between partitions and ensures thattwo independent (non-communicating) partitions running on the samecomputer cannot affect each other in any way. The information and flowand separation policies are enforced via the following mechanisms: Memory Protection,Memory Partitioning, Periods Processing, Mandatory Access Control, andTime Partitioning

Memory Protection. Thecomputer's memory protection hardware is configured by the separationkernel to prevent any read or write access between partitions. Thekernel runs in its own partition and is also protected from any otheruser application. Not only does this mean that a rogue applicationcannot corrupt another application by writing into its address space,but it also means that a rogue application cannot read sensitiveinformation from the kernel or another application.

Figure1 ” central memory store is a security risk

Memory Partitioning. Anotherway a rogue application can affect another application is by gobblingup all of the memory in the system, causing other applications to fail(see Figure 1 above ). Mostoperating systems employ a central store for memory that is doled outto applications as they request new threads, dynamic memoryallocations, or other resources. The separation kernel must thwart thisdenial of service attack. One method is to allocate a fixed quota ofphysical memory to each application. If an application exhausts itsquota, it can fail, but it cannot possibly affect the memory usage ofother applications (see Figure 2 below ).

Figure2 ” separation kernel uses quotas to guarantee memory availability

When switching from execution of one partitioned application toanother, no latent information (such as data on the stack or inregisters) from the old partition is permitted to be read by the newpartition; in other words, the kernel must scrub any resources ofinformation before they can be reused. This requirement is aimed atcomputer systems that manipulate data at multiple security levels (e.g.top secret and unclassified).

If the separation does not implement periods processing, then aninsecure, subverted partition (e.g. with internet access) may be ableto gain access to classified information left over from a top secretpartition's earlier execution. This information could then be sent overthe internet for collection and use by hostile entities.

Mandatory Access Control. Asecure operating system must control access to critical systemresources, such as files and I/O devices, in order to preventcompromise of those resources by rogue applications.

Mandatory access control (MAC) policies are enforced by theoperating system and cannot be modified by user applications. Theseparation kernel should provide mandatory access control over kernelobjects such as I/O devices, semaphores, and threads.

Similarly, inter-partition communication policies are implementedand enforced by capabilities to communication objects. Ideally, thesystem designer should be able to specify object ownership at buildtime using a configuration file that is then input into the buildprocess where it is incorporated into the separation kernel.

At boot time, the separation kernel reads the configuration data andimplements the access control policy. A more dynamic access controlmechanism can be built on top of the separation kernel's static policyquite easily (more on building higher-level security policies later).

Figure 3, below shows anexample configuration depicted graphically. In this example, the systemconsists of three partitions. The top_secret partition has beenprovided access to the ClassifiedNetworkDevice; neither the secret norunclassified partitions have access to this device, and there is no waythey can obtain access during run-time.

Figure3 ” mandatory access control by partition

Time Partitioning. Anotherimportant feature of the separation kernel is to guarantee CPUexecution time to partitions. A simple denial of service attack towhich insecure operating systems are vulnerable entails a rogueapplication spawning multiple copies of itself or another application,with each “confederate” process soaking up an increasing share of thesystem CPU time.

Critical applications are unable to execute, causing system-levelfailures. Most operating system schedulers have no provision forguaranteeing execution time at the partition level. Many real-timeoperating systems schedule threads by priority, without regard to theapplications in which the threads reside.

Therefore, bugs or design errors can cause threads running in acritical partition to be starved of execution time by threads runningin unrelated, non-critical partitions. Desktop operating systems oftenuse fairness-based heuristic scheduling algorithms that also fail toprovide any execution time guarantees.

The separation kernel can provide guaranteed execution time topartitions by scheduling at the partition level. One such algorithm isdefined by ARINC-653, a standard for operating system execution widelyadopted in the avionics industry. The ARINC-653 partition schedulerschedules partitions in a repeating timeline (see Figure 4, below ).

Partitions are allocated slots within the timeline; when apartition's slot is running, only threads within that partition canrun. There is nothing any other partition can do to steal CPU cyclesaway from the active partition.

Figure4 ” partition scheduling

Damage Control
The separation kernel does not address network security. Ideally, ahigh assurance network servicing infrastructure is used on top of theseparation kernel. However, even if there are flaws in higher-levelsecurity policies, the partitioning capabilities of the separationkernel can limit damage from security infiltrations and effectivelythwart hackers.

Consider a SCADA system that has a networked administrator interfaceand safety critical applications such as a health monitor. Authorizedtechnicians use a PDA to wirelessly connect to the system to controlits operation and configuration. The SCADA system has low assurancenetwork security but a high assurance separation kernel controlling theSCADA computer.

Due to a flaw in the computer's low assurance web server, acyberterrorist is able to use the network interface to load a virusonto the computer. The virus duplicates itself, but eventually it willexhaust its memory quota and further duplication efforts will fail.Memory use within the critical applications is unaffected.

Suppose the duplicated virus processes attempt to raise theirpriorities and spin, soaking up as much execution time as they can.Once again, the time partitioning enforced by the separation kernelensures that the virus cannot steal CPU cycles from the preloadedcritical applications.

Finally, because of memory protection enforced by the separationkernel, the virus is unable to access beyond the loading partition toread from or write to the kernel or critical applications.

MILS Architecture
Multiple Independent Levels of Security and Safety (MILS) is a jointresearch effort between academia, industry, and government to developand implement a high assurance, real-time architecture for embeddedsystems. The goal of the MILS architecture is to ensure that all systemsecurity policies are non-bypassable, evaluatable, always-invoked, andtamper-proof.

The aforementioned separation policies, and the formal assurance ofthese policies, makes the separation kernel a perfect fit to providethe foundation of the MILS system. In fact, the term “MILS SeparationKernel” is often used. Another key aspect of the MILS vision is toenable security policies to be enforced at hierarchical levels,depending on the requirements of the overall system. For example,instead of incorporating an MLS (Multi-level Security) control flowpolicy into the separation kernel, MILS promotes the concept ofbuilding an MLS policy at the application level by utilizing theunderlying separation policies of the kernel.

Because high assurance components are built as application programsrunning on top of the separation kernel, they are, by definition,optional. If a system requires a single shared network connection formultiple levels of data, then the PCSExpress component can be added. Ifeach level of data has a private network connection, then PCSexpresscan be omitted. This maximizes flexibility and performance whilereducing cost on many fronts.

In order to elucidate how domain-specific security policies can beefficiently built on top of separation policies, consider how the MLSwindow manager works. Each window running at a different security levelis provided a virtual frame buffer. The separation kernel's accesscontrol policies prevent any of the windows from gaining direct accessto the graphics card's physical frame buffer.

Only the high assurance window manager has direct access to thehardware. Applications write to their virtual screens whenever they arescheduled, according to the separation kernel-enforced timepartitioning policy. Independently, the high assurance window managerperiodically (again, according to the scheduling policy) takes datafrom the virtual screen buffers and splashes them on the physicaldevice.

None of the applications can directly read into screen real-estateof other applications running at different security levels (this isenforced via the mandatory access controls/capabilities). And theapplications are unable to detect when other levels are writing to thescreen, thereby preventing a covert (yet obvious) timing channel.

Conclusion
It is because of its partitioning features and its lean, evaluatabledesign, that the separation kernel is the foundation of a securesystem. High assurance is required for the embedded operating systemsthat control today's, and tomorrow's, safety and security criticalsystems. The security policies of operating system components must notfail; high assurance is the only path to this goal.

Using the MILS architecture, we can create hierarchical buildingblocks of secure components, each of which is independentlyevaluatable, to compose even the most complex security systems (such assecure workstations and servers), and do it in a manner that iscost-effective relative to legacy security kernel architectures. The”cookbook” approach of Common Criteria, which enables evaluations to beperformed on arbitrary classes of components, makes it an ideal fit forthe MILS architecture.

DavidN. Kleidermacher is Vice President of Engineering at Green HillsSoftware, Inc.

This article is excerpted from apaper of the same name presented at the Embedded Systems ConferenceSilicon Valley 2006. Used with permission of the Embedded SystemsConference. For more information, please visit www.embedded.com/esc/sv.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.