Why does MLS matter?

Learn about BlueSpace for Information Assurance Specialists

Multi-Level Security has been an elusive goal that has failed to achieve broad adoption for over three decades. What has changed with the new wave is the convergence of MLS with virtualization.

MLS is not a new requirement – its origins can be dated back to MULTICS and a history of special projects since then.

Multi-level security is defined as follows in the CNSSI 4009 glossary:

Concept of processing information with different classifications and categories that simultaneously permits access by users with different security clearances and denies access to users who lack authorization.”

This requires the enforcement of Mandatory Access Controls (MAC), and if the system is to be accessed by end users, this requires MAC enforcement at the end user interface level.

Historically, MLS applications have attempted to achieve a MAC stack, with labeling implemented in the file store, often using Access Control Lists (ACLs). This has led to highly customized derivates of commercial software, or custom applications created from scratch. Most of these applications relied (in the recent past) on Trusted Solaris or SE Linux to provide a labeled operating system.

In the past two decades, Microsoft Windows has come to dominate the end user application ecosystem, but there is no labeling in Microsoft Windows, and this is unlikely to change. Custom MLS applications written natively on UNIX have been unable to keep up with the pace of development of applications such as Microsoft Outlook.

More recent infrastructure approaches have focused on leveraging virtualization to run multiple separate instances of end user applications in separate Windows desktops, delivered as virtual machines or remote terminal sessions. AFRL SABER (based on Solaris 10 TX, NSA’s HAP and the emerging RTOS solutions (e.g. OB1) are all based on this concept of a trusted hypervisor / thin client for running MILS applications.

While these trusted client workstations can help with infrastructure consolidation, they do not by themselves facilitate MLS, because the user still has separate user interfaces running at each security domain. UCDMO has classified these devices as Cross Domain Access.

BlueSpace MLS applications run on top of these MILS type workstations, and can provide a user with a single interface that spans multiple domains, for example:

  • Unity: One inbox for all your email, one calendar for all your meetings.

  • Discover: One search for all your intelligence sources.

  • GeoSpace: One geospatial view for C2 operations.

The US Government provided funding to BlueSpace to develop some of the components of the Discover application as part of the Comprehensive National Cybersecurity Initiative.

All the BlueSpace multi-level applications have a fused high view at the dominant domain of metadata (e.g. email headers to build an inbox), but clicking to open or interact with the content causes a window to open automatically at the appropriate (original) domain corresponding to that content item.

BlueSpace orchestrates a single user interface that spans multiple separate Windows desktops on a trusted hypervisor / thin client, using seamless windowing to enable labeled windows to popup at the right domain. Messages to orchestrate this unified interface are transferred between domains across BlueSpace’s Trusted Service Bus – an administratively controlled message pipeline.

All cross-domain activity is centralized through this Trusted Service Bus, where it can be validated, filtered and audited. Backend applications (such as Google Search Appliances and Microsoft Exchange Servers) can be used without modification to their code bases or elevated privileges. The Trusted Service Bus as well as instances of the Mashup Server and Application Server for a specific application are maintained on an Application Appliance hosted in the cloud that connects to all the networks. Each user’s desktop has a set of single level processes (running in each domain) to connect to the Application Appliances.

This approach has the following advantages:

  • Impact on existing COTS applications is minimized.

  • Backend applications can be patched without significant impact on the MLS accreditation.

  • All MLS applications can use the same Trusted Service Bus application for cross-domain orchestration.

  • The code base of the Trusted Service Bus is of a similar size to an RTOS, and so can be rigorously inspected.

BlueSpace middleware is available to be embedded for free in MLS infrastructure programs, and BlueSpace is in discussions with the major MLS desktop programs to do this. BlueSpace expects to support an ICD 503 accreditation of its Unity and Discover applications during 2010 as an optional module on the AFRL SABER baseline. BlueSpace expects to commence a DIACAP process during 2011.

Learn more about our solutions Learn more about our products