ON THE SOFTER SIDE

MILS: High-Assurance Security at Affordable Costs

Without Multiple Independent Levels of Security (MILS), integrators have to implement each level of security function individually on a separate processor. The MILS architecture on a single processor is both cost-effective and possible with today’s technology.

JOE JACOB, OBJECTIVE INTERFACE SYSTEMS

Keywords in this Article:

No Keywords

  • Page 1 of 4
    Bookmark and Share

Over the past five years market forces have coalesced to support a dramatically simpler foundational architecture, called “MILS,” for building high-assurance systems that must survive high-threat environments. Multiple Independent Levels of Security (MILS) is a departure from operating system architectures that were designed prior to the Internet, when there was little threat of network attacks. As a result, these early systems did not incorporate security as a design requirement. In response to inevitable failures and intrusions, patches were developed over time to plug specific security holes. This “fail first, patch later” approach is unacceptable for any mission-critical system.

The central idea behind MILS is to partition a system in such a way that: 1) the failure or corruption of any single partition cannot affect any other part of the system or network, or, 2) each partition can be security-evaluated and certified separately, so no partition requires evaluation at a higher level than necessary for that function. For the first time, developers can base their applications on secure, high-assurance foundations.

Multiple Levels of Security for Multifunctional Systems

In the early 1980s, the DoD issued the “Orange Book,” a set of criteria used for evaluating the security features of computer systems. It became widely used in the IT industry as a benchmark for security standards. However, Orange Book security fell short in two areas. First, higher assurance levels required both mathematical verification of trusted system components, as well as significant security functionality in those trusted system components. The code size made mathematical verification almost impossible. Secondly, intersystem communication was not addressed by the Orange Book. Trusted components and device drivers ran in privileged mode for performance reasons. Security-critical application code also ran in privileged mode. This was a nightmare to evaluate, and typical evaluations cost on the order of $100 million.

As a result, implementing Orange Book standards became expensive and problematic, mainly because of the limitations of microprocessors in the 1980s. The tremendous increase in microprocessor performance has enabled new paradigms of security. Often, one system has the job of performing several different functions, especially as processors increase in performance. If such a multifunctional system must meet different levels of safety or security criteria for each of its functions, there must be some guarantee that lower-security functions cannot interfere with higher-level functions—under any circumstances.

Such systems require Multiple Independent Levels of Security, or MILS, as the NSA designates them. MILS system designers must guarantee that unintended interactions are not possible. Otherwise, systems integrators would have to integrate each function individually on a separate processor, which would increase costs and system complexity. In some applications, such as fighter aircraft, separate processors would also add weight, take up space, and consume power—a serious design drawback. MILS implementation on a single processor is both cost-effective and possible with today’s technology. MILS is not a revolution of new ideas over old, but old ideas coming of age—now that technology has caught up.

One Size Does Not Fit All

MILS combines the best of the safety and security worlds to create a better solution than either could have devised alone. It draws upon FAA DO-178B Level A Safety technology and Common Criteria EAL7 Security technology to enable MILS Web and network services for mission-critical embedded and real-time systems, including high-assurance weapons, training and communications systems and C4I platforms.

MILS is founded on the understanding that security is not a one-size-fits-all proposition, and that the security level should be appropriate to the application. The Common Criteria’s Evaluation Assurance Levels range from EAL1, the very basic level, to EAL7, the highest level of assurance. Various military systems require EAL assurance levels according to the value of their data and the threat that they encounter. A set of assurance requirements between EAL6 and EAL7, called “High Robustness,” is required when top secret, secret, confidential and unclassified data reside on the same node.

Discuss

Nick P April 29, 2010 – 10:47pm

First off, I want to say this is an excellent article. I hope you guys don't mind me using most of it, giving due credit of course, to explain MILS and your CORBA technology to others. There was one claim that troubled me, though: the routine $100 million evaluation cost. I've read up on some A1-class systems, like SCOMP and LOCK, that were $10-$30 million each for relatively small product. Many times when I see extraordinary sums like the $100 million figure, the author has taken the cost of a smaller project, converted it to $ per line of code or manhour, then estimated the cost of a larger system by extrapolation. Whether relevant for this example or not, this is a faulty technique. Good high assurance engineers are almost ingeniously clever about reducing the evaluated TCB, whether reusing/leveraging other components (a MILS approach, actually) or using novel architecture/algorithms to ensure small or simple TCB. An example is the Micro-SINA project using the Nizza architecture to reduce the security-critical TCB by 95%. Because of these issues, the cost of increased assurance is non-linear and assurance extrapolations are often unreliable. I'm genuinely curious about the $100 million claim. Was this an extrapolation or is it from a real-world evaluation? If so, what was the systems purpose, type, and construction effort? Such data is important for project managers considering high assurance techniques. The most informative data of this kind so far was Smith's breakdown of the cost of LOCK. Thanks for your time ahead of time, Nick P

LEAVE A COMMENT