XTS-400

Infobox_OS
name = XTS-400
website = [http://www.baesystems.com/ProductsServices/bae_prod_csit_xts400.html www.baesystems.com]
developer = BAE Systems
source_model = Closed source
latest_release_version = 6.5
latest_release_date = August 2008
kernel_type = Monolithic kernel
working_state = Current
supported_platforms = x86The XTS-400 is a multi-level secure computer system. It is multi-user and multi-tasking. 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 "STOP" (for Secure Trusted Operating Program) operating system. XTS-400 was developed by BAE Systems, and was originally released as version 6.0 in December of 2003.

STOP provides "high-assurance" security and, as of July 18, 2006, is the only 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, concurrent 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 binary compatibility with Linux applications running most Linux commands and tools as well as most Linux applications without the need for recompiling. This untrusted 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, STOP provides a set of proprietary APIs to applications. In order to develop programs that use these proprietary APIs, a special software development environment (SDE) is needed. The SDE is also needed in order to port some complicated Linux/Unix applications to the XTS-400.

A new version of the STOP operating system, [http://www.baesystems.com/ProductsServices/bae_prod_csit_xtsstop7.html STOP 7] has since been introduced, with claims to improved performance and new features such as RBAC.

Uses

As a high-assurance, MLS system, XTS-400 can be used in "cross-domain" solutions. A cross-domain solution will typically require 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 purchased in a rack-mount configuration, accepts a 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 [http://www.digitalnet.com/solutions/information_assurance/xts300sol_ste.htm] .

ecurity

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 both 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 it's 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 [http://www.niap-ccevs.org/cc-scheme/vpl/] [http://www.commoncriteriaportal.org/products_OS.html#OS]

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 U.S. DoD 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/Linux, including the presence of access control lists on every object. Set-id functionality 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 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. Thus, even if, for example, a user downloads a virus, the virus will be unable to corrupt or affect the operating 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, 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 trusted security functions (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 can not 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 U.S. National Security Agency.

Hardware

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 available, including rack-mount and tower form factors. The XTS-400 uses only standard PC, COTS components, except for an optional MSCU (see above).

The hardware is based around an Intel Xeon (P4) CPU at up to 2.8GHz speeds. Up to 2 GB of main memory is supported.

A 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.

History

The XTS-400 has been preceded by several evaluated ancestors, all developed by the same group: SCOMP (Secure Communications Processor), "XTS-200", and "XTS-300". All of the predecessor products were evaluated under 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 programming API of Linux. 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".

Architecture

STOP is a monolithic kernel operating system (as is Linux). Though it provides a Linux-like API, STOP was not based on Unix or Linux source. STOP is highly layered and highly modularized and relatively small 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 DECL-KRUT 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 to the User Access Authentication database, kept at "system high", while establishing a session for a user at a lower sensitivity level.

Potential weaknesses

The XTS-400 can provide a high level of security in many application environments, but trade-offs are made to attain that security. Potential weaknesses for some customers may include:
* Slower 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 weak command line features.
* Limited hardware choices.
* Not intended for embedded or real-time solutions.

External links

* [http://www.baesystems.com/ProductsServices/bae_prod_csit_xts400.html BAE's XTS-400 product page]
* [http://www.niap-ccevs.org/cc-scheme/st/vid10293 XTS-400 EAL5+ validated product page]
* [http://www.niap-ccevs.org/cc-scheme/st?vid=3012 XTS-400 EAL5+ validated product page]
* [http://www.niap-ccevs.org/cc-scheme/st?vid=9503 XTS-400 EAL4+ validated product page]
* [http://patft.uspto.gov/netacgi/nph-Parser?TERM1=7103914&u=/netahtml/srchnum.htm&Sect1=PTO1&Sect2=HITOFF&p=1&r=0&l=50&f=S&d=PALL United States Patent 7,103,914: Trusted computer system]
* [http://www.nsa.gov/selinux/papers/inevitability/ Paper on the need for secure operating systems and mandatory security]
* [http://www.digitalnet.com/solutions/information_assurance/xts300sol_ste.htm Guards and secure solutions using the XTS-300 System]
* [http://cisr.nps.navy.mil/projects/mysea.html Monterey Security Architecture (MYSEA)] , a Naval Postgraduate School project which utilized the STOP OS
* [http://www.sensornet.gov/net_ready_workshop/Boyd_Fletcher_CDCIE_XMPP_Overview_for_NetReadySensors_Conf.pdf XMPP & Cross Domain Collaborative Information Environment (CDCIE) Overview] , multinational information sharing in both single and cross domain environments (utilizes STOP OS)
* [http://www.afcea.org/wiki/index.php?title=Trusted_Computing_Base Trustifier TCB overview]