The XTS-400 is a multi-level secure computer operating system . It is multi-user and multitasking that uses multilevel scheduling in processing data and information. It works in networked environments and supports Gigabit Ethernet and Both IPv4 and IPv6 .
The XTS-400 is a combination of Intel x86 hardware and the Secure Operating System Operating System ( STOP ) . XTS-400 was developed by BAE Systems , and originally released as version 6.0 in December 2003.
STOP provides high-assurance security and was the first general-purpose operating system with a Common Criteria assurance level rating of EAL5 or above.  The XTS-400 can host, and be trusted to separate, multiple, competitor data sets, users, and networks at different sensitivity levels.
The XTS-400 Provides Both an untrusted environment for normal work and a trusted environment for administrative work and for privileged applications. The untrusted environment is similar to traditional Unix environments. It provides the most compatible Linux applications and the most Linux applications. This unstable environment includes an X Window System GUI, though all windows on a screen must be at the same sensitivity level.
To support the trusted environment and various security features, provides a set of proprietary APIs to applications. These are proprietary APIs, a special software development environment (SDE) is needed. The SDE is also needed to port some complicated Linux / Unix applications to the XTS-400.
A new version of the STOP operating system, STOP 7  has been introduced, with claims to have improved performance and new features such as RBAC .
As a high-assurance, MLS system, XTS-400 can be used in cross-domain solutions , which typically requires a piece of privileged software. 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, typing Unix command line tools , and a GUI are present in support of a desktop solution. Since the XTS-400 multiple media, competitor network connections at different sensitivity levels, it can be used to replace several single-level desktops connected to several different networks.
In carrier of server functionality, the XTS-400 can be Implemented in a rack mount configuration specified, accepts a uninterruptible power supply (UPS), multiple Allows network connections, accommodates Many hard disks was 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-security 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), both profiles are surpassed in functionality and insurance.
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 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 by the National Security Agency .
The official postings for all the XTS-400 reviews can be seen on the Validated Product List.  
The main security feature that sets STOP apart from most operating systems. Support for a mandatory integrity policy, also sets STOP apart from most MLS or trusted systems. While a policy deals with sensitivity Preventing unauthorized disclosure, an integrity policy deals with Preventing unauthorized deletion or modification (Such As the damage That a virus might attempt). Normal (ie, untrusted) users do not have the discretion to change the sensitivity or integrity levels of objects. The Bell-LaPadula and Biba 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 of the United States Department of Defense’s data sensitivity classification model (ie, “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 any information; the user’s identification is used for access to auditing mechanisms by 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 permits some of the functionality of trusted systems which support a full type enforcement or domain-type enforcement policy;
- Auditing of all security-related events and trusted tools to allow administrators to detect and analyze potential security breaches;
- Trusted path , which allows a user to be sure he / she is interacting 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;
- Insulation of the operating system code and data files from the activity of untrusted users and processes qui, In Particular, Prevents malware gold from corrupting Otherwise Affecting the system;
- Separation of processes from one another (so that one process / user can not tamper with the internal data and code of another process);
- Reference monitor functionality, which can not be accessed by the operating system;
- Strong separation of administrator, operator, and user roles using the mandatory integrity policy;
- Residual information (ie, 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;
- Excluding TSF from a higher level of network services, so that the TSF is not susceptible to the known known vulnerabilities in those services.
STOP comes in only one package, so there is no confusion about a particular package. Mandatory policies can not be disabled. Policy configuration does not require a large number of 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 pollinated by the United States National Security Agency .
The CC evaluation forces particular hardware to be used in the XTS-400. Though these restrictions 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 Intel Xeon ( P4 ) central processing unit (CPU) has 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 high-performance device 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 developed by Secure Communications Processor (SCOMP), XTS-200, and XTS-300. All of the predecessor products have been evaluated under the Trusted Computer Criteria Evaluation System (TCSEC) (aka Orange Book ) standards. SCOMP completed evaluation in 1984 at the highest functional and insurance 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-hardware 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 (aka RAMP), very similar to an assurance of continuity cycle under CC, and finally 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 XTS system has some restrictions on the API and require additional, proprietary interfaces, conformance is more likely than most applications to run XTS without recompilation. Some security features were also improved.
As of July 2006, continued enhancements 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 operating system kernel (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 is further subdivided into layers. The innermost ring has hardware privileges 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 hand of every process’s address space and is needed by ordinary and privileged Both 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.
1. TSS implements file systems, TCP / IP implementations , and enforces the discretionary access control policy on file system objects. TSS’s data is local to the process within which it is executing.
OSS provides Linux-like APIs for applications providing additional proprietary interfaces for 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 to which the system depends on the security policy (eg, the establishment of user authorization). This determination is based on integrity 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 applications environments, but trade-offs are made to reach it. Potential weaknesses for some customers may include:
- Lower performance due to more rigid internal layering and modularity and 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 use a GUI and has limited command line features;
- Limited hardware choices;
- Not suitable for embedded or real-time environments.