XTS-400

As a high-assurance, MLS system, XTS-400 can be used in cross-domain solutions, which typically need a piece of privileged software to be developed which can temporarily circumvent one or more security features in a controlled manner. Such pieces are outside the CC evaluation of the XTS-400, but they can be accredited.

The XTS-400 can be used as a desktop, server, or network gateway. The interactive environment, typical Unix command line tools, and a GUI are present in support of a desktop solution. Since the XTS-400 supports multiple, concurrent network connections at different sensitivity levels, it can be used to replace several single-level desktops connected to several different networks.

In support of server functionality, the XTS-400 can be implemented in a rackmount configuration, accepts an uninterruptible power supply (UPS), allows multiple network connections, accommodates many hard disks on a SCSI subsystem (also saving disk blocks using a sparse file implementation in the file system), and provides a trusted backup/save tool. Server software, such as an Internet daemon, can be ported to run on the XTS-400.

A popular application for high-assurance systems like the XTS-400 is to guard information flow between two networks of differing security characteristics. Several customer guard solutions are available based on XTS systems.

XTS-400 version 6.0.E completed a Common Criteria (CC) evaluation in March 2004 at EAL4 augmented with ALC_FLR.3 (validation report CCEVS-VR-04-0058.) Version 6.0.E also conformed with the protection profiles entitled Labeled Security Protection Profile (LSPP) and Controlled Access Protection Profile (CAPP), though both profiles are surpassed in functionality and assurance.

XTS-400 version 6.1.E completed evaluation in March 2005 at EAL5 augmented with ALC_FLR.3 and ATE_IND.3 (validation report CCEVS-VR-05-0094), still conforming to the LSPP and CAPP. The EAL5+ evaluation included analysis of covert channels and additional vulnerability analysis and testing by the National Security Agency.

XTS-400 version 6.4.U4 completed evaluation in July 2008 at EAL5 augmented with ALC_FLR.3 and ATE_IND.3 (validation report CCEVS-VR-VID10293-2008), also still conforming to the LSPP and CAPP. Like its predecessor, it also included analysis of covert channels and additional vulnerability analysis and testing by the National Security Agency.

The official postings for all the XTS-400 evaluations can be seen on the Validated Product List.[3][4]

The main security feature that sets STOP apart from most operating systems is the mandatory sensitivity policy. Support for a mandatory integrity policy, also sets STOP apart from most MLS or trusted systems. While a sensitivity policy deals with preventing unauthorized disclosure, an integrity policy deals with preventing unauthorized deletion or modification (such as the damage that a virus might attempt). Normal (i.e., untrusted) users do not have the discretion to change the sensitivity or integrity levels of objects. The Bell–LaPadula and Biba formal models are the basis for these policies.

Both the sensitivity and integrity policies apply to all users and all objects on the system. STOP provides 16 hierarchical sensitivity levels, 64 non-hierarchical sensitivity categories, 8 hierarchical integrity levels, and 16 non-hierarchical integrity categories. The mandatory sensitivity policy enforces the United States Department of Defense data sensitivity classification model (i.e., "Unclassified," "Secret," "Top Secret"), but can be configured for commercial environments.

Other security features include:

• Identification and authentication, which forces users to be uniquely identified and authenticated before using any system services or accessing any information; the user's identification is used for access control decisions and for accountability via the auditing mechanism;
• Discretionary access control (DAC), which appears just as in Unix, including the presence of access-control lists on every object; the set-id function is supported in a controlled fashion;
• A mandatory subtype policy, which allows some of the functionality of trusted systems which support a full type enforcement or domain-type enforcement policy;
• Auditing of all security-relevant events and trusted tools to allow administrators to detect and analyze potential security violations;
• Trusted path, which allows a user to be sure s/he is interacting directly with the trusted security functions (TSF) during sensitive operations; this prevents, for example, a Trojan horse from spoofing the login process and stealing a user's password;
• Isolation of the operating system code and data files from the activity of untrusted users and processes which, in particular, prevents malware from corrupting or otherwise affecting the system;
• Separation of processes from one another (so that one process/user cannot tamper with the internal data and code of another process);
• Reference monitor functionality, so that no access can bypass scrutiny by the operating system;
• Strong separation of administrator, operator, and user roles using the mandatory integrity policy;
• Residual information (i.e., object reuse) mechanisms to prevent data scavenging;
• Trusted, evaluated tools for configuring the system, managing security-critical data, and repairing file systems;
• Self-testing of security mechanisms, on demand;
• Exclusion of higher layer network services from the TSF, so that the TSF is not susceptible to the publicly known vulnerabilities in those services.

STOP comes in only a single package, so that there is no confusion about whether a particular package has all security features present. Mandatory policies cannot be disabled. Policy configuration does not require a potentially complicated process of defining large sets of domains and data types (and the attendant access rules).

To maintain the trustworthiness of the system, the XTS-400 must be installed, booted, and configured by trusted personnel. The site must also provide physical protection of the hardware components. The system, and software upgrades, are shipped from BAE Systems in a secure fashion.

For customers who want them, XTS-400 supports a Mission Support Cryptographic Unit (MSCU) and Fortezza cards. The MSCU performs type 1 cryptography and has been separately scrutinized by the United States National Security Agency.

The CC evaluation forces particular hardware to be used in the XTS-400. Though this places restrictions on the hardware configurations that can be used, several configurations are possible. The XTS-400 uses only standard PC, commercial off-the-shelf (COTS) components, except for an optional Mission Support Cryptographic Unit (MSCU).

The hardware is based on an Intel Xeon (P4) central processing unit (CPU) at up to 2.8 GHz speeds, supporting up to 2 GB of main memory.

A Peripheral Component Interconnect (PCI) bus is used for add-in cards such as Gigabit Ethernet. Up to 16 simultaneous Ethernet connections can be made, all of which can be configured at different mandatory security and integrity levels.

A SCSI subsystem is used to allow a number of high-performance peripherals to be attached. One SCSI peripheral is a PC Card reader that can support Fortezza. Multiple SCSI host adapters can be included.

The XTS-400 has been preceded by several evaluated ancestors, all developed by the same group: Secure Communications Processor (SCOMP), XTS-200, and XTS-300. All of the predecessor products were evaluated under Trusted Computer System Evaluation Criteria (TCSEC) (a.k.a. Orange Book) standards. SCOMP completed evaluation in 1984 at the highest functional and assurance level then in place: A1. Since then the product has evolved from proprietary hardware and interfaces to commodity hardware and Linux interfaces.

The XTS-200 was designed as a general-purpose operating system supporting a Unix-like application and user environment. XTS-200 completed evaluation in 1992 at the B3 level.

The XTS-300 transitioned from proprietary, mini-computer hardware to COTS, Intel x86 hardware. XTS-300 completed evaluation in 1994 at the B3 level. XTS-300 also went through several ratings maintenance cycles (a.k.a. RAMP), very similar to an assurance continuity cycle under CC, ultimately ending up with version 5.2.E being evaluated in 2000.

Development of the XTS-400 began in June 2000. The main customer-visible change was specific conformance to the Linux API. Though the security features of the XTS system put some restrictions on the API and require additional, proprietary interfaces, conformance is close enough that most applications will run on the XTS without recompilation. Some security features were added or improved as compared to earlier versions of the system and performance was also improved.

As of July 2006, enhancements continue to be made to the XTS line of products.

On September 5, 2006, the United States Patent Offices granted BAE Systems Information Technology, LLC. United States Patent # 7,103,914 "Trusted computer system".

STOP is a monolithic kernel operating system (as is Linux). Though it provides a Linux-compatible API, STOP is not derived from Unix or any Unix-like system. STOP is highly layered, highly modularized, and relatively compact and simple. These characteristics have historically facilitated high-assurance evaluations.

STOP is layered into four rings and each ring is further subdivided into layers. The innermost ring has hardware privilege and applications, including privileged commands, run in the outermost. The inner three rings constitute the kernel. Software in an outer ring is prevented from tampering with software in an inner ring. The kernel is part of every process's address space and is needed by both normal and privileged processes.

A security kernel occupies the innermost and most privileged ring and enforces all mandatory policies. It provides a virtual process environment, which isolates one process from another. It performs all low-level scheduling, memory management, and interrupt handling. The security kernel also provides I/O services and an IPC message mechanism. The security kernel's data is global to the system.

Trusted system services (TSS) software executes in ring 1. TSS implements file systems, implements TCP/IP, and enforces the discretionary access control policy on file system objects. TSS's data is local to the process within which it is executing.

Operating system services (OSS) executes in ring 2. OSS provides Linux-like API to applications as well as providing additional proprietary interfaces for using the security features of the system. OSS implements signals, process groups, and some memory devices. OSS's data is local to the process within which it is executing.

Software is considered trusted if it performs functions upon which the system depends to enforce the security policy (e.g., the establishment of user authorization). This determination is based on integrity level and privileges. Untrusted software runs at integrity level 3, with all integrity categories, or lower. Some processes require privileges to perform their functions—for example the Secure Server needs to access the User Access Authentication database, kept at system high, while establishing a session for a user at a lower sensitivity level.

The XTS-400 can provide a high level of security in many application environments, but trade-offs are made to attain it. Potential weaknesses for some customers may include:

• Lower performance due to more rigid internal layering and modularity and to additional security checks;
• Fewer application-level features available out-of-the-box;
• Some source level changes may be necessary to get complicated applications to run;
• The trusted user interface does not utilize a GUI and has limited command line features;
• Limited hardware choices;
• Not suited for embedded or real-time environments.

• Official website, BAE
• XTS-400 EAL5+ validated product page
• XTS-400 EAL5+ archived validated product page
• XTS-400 EAL4+ archived validated product page
• United States Patent 7,103,914: Trusted computer system
• Paper on the need for secure operating systems and mandatory security
• Monterey Security Architecture (MYSEA), a Naval Postgraduate School project which utilized the STOP OS
• XMPP & Cross Domain Collaborative Information Environment (CDCIE) Overview, multinational information sharing in both single and cross domain environments (utilizes STOP OS)