Multiple Single-level - Cross-domain Solutions

Cross-domain Solutions

MSL systems, whether virtual or physical in nature, are designed to preserve isolation between different classification levels. Consequently (unlike MLS systems), an MSL environment has no innate abilities to move data from one level to another.

To permit data sharing between computers working at different classification levels, such sites deploy cross-domain solutions (CDS), which are commonly referred to as gatekeepers or guards. Guards, which often leverage MLS technologies themselves, filter traffic flowing between networks; unlike a commercial Internet firewall, however, a guard is built to much more stringent assurance requirements and its filtering is carefully designed to try to prevent any improper leakage of classified information between LANs operating at different security levels.

Data diode technologies are used extensively where data flows are required to be restricted to one direction between levels, with a high level of assurance that data will not flow in the opposite direction. In general, these are subject to the same restrictions that have imposed challenges on other MLS solutions: strict security assessment and the need to provide an electronic equivalent of stated policy for moving information between classifications. (Moving information down in classification level is particularly challenging and typically requires approval from several different people.)

As of late 2005, numerous high-assurance platforms and guard applications have been approved for use in classified environments. N.b. that the term "high-assurance" as employed here is to be evaluated in the context of DCID 6/3 (read "dee skid six three"), a quasi-technical guide to the construction and deployment of various systems for processing classified information, lacking both the precise legal rigidity of the Orange Book criteria and the underlying mathematical rigor. (The Orange Book is motivated by, and derived from, a logical "chain of reasoning" constructed as follows: a "secure" state is mathematically defined, and a mathematical model is constructed, the operations upon which preserve secure state so that any conceivable sequence of operations starting from a secure state yields a secure state; a mapping of judiciously chosen primitives to sequences of operations upon the model; and a "descriptive top-level specification" that maps actions that can be transacted at the user interface (such as system calls) into sequences of primitives; but stopping short of either formally demonstrating that a live software implementation correctly implements said sequences of actions; or formally arguing that the executable, now "trusted," system is generated by correct, reliable tools .)