A Survey of Security Concepts for Common Operating Environments Joseph Loyall, Kurt Rohloff, Partha Pal, Michael Atighetchi

Raytheon BBN Technologies Cambridge, USA

{jloyall,krohloff,ppal,matighet}@bbn.com

Abstract—As newer software engineering technologies, such as Service-Oriented Architecture (SOA), become the basis for mission-critical systems, they must include security as a foun-dational capability. This paper highlights security concepts relevant to using SOA as a foundation for a Common Operat-ing Environment (COE), i.e., a set of infrastructure and com-mon services for developing and executing applications across multiple platforms. We present and motivate security needs, tradeoffs, and solutions in the various layers of a SOA-based COE, including 1) the network, 2) computational platforms, and 3) the common software infrastructure consisting of a SOA stack, common services, and applications. We also discuss cross cutting aspects of security such as survivability, transpa-rency, flexibility, specificity, reuse, and assurance. We then explore security standards and requirements for mission-critical systems developed on top of a SOA-based COE and security technologies that are candidates for satisfying the re-quirements. The paper closes with a set of recommendations and steps forward for both research into and implementation of security in a SOA-based COE.

Keywords: Security, Service-Oriented Architecture, Multi-Level Security, Cross Domain, Adaptive Survivability

I. INTRODUCTION Building mission-critical systems as stove-piped systems

from the ground up has become untenable in terms of ex-pense and maintainability. Stove-piped systems built from scratch quickly become legacy and are outpaced by commer-cial and off-the-shelf technology, which they cannot adopt without major re-architecture and re-implementation.

This situation has become widely acknowledged by the industries and institutions that develop mission-critical sys-tems, including the US Department of Defense, the aero-space industry, the health care, and financial industries. This has led to the search for common operating environments (COEs) and the adoption of modern software engineering technologies, such as service-oriented architecture (SOA) and SOA-based software stacks in building COEs. A COE is a set of infrastructure and common services for building and executing applications on multiple platforms [29]. A COE enables suites of applications and systems for multiple do-mains to be built with lower cost, improved code reuse, and with improved portability and maintainability.

Security is a critical aspect of any COE. For a COE to be useful, it must include the features necessary to ensure prop-er controls against unauthorized use and protection of critical services and data. The security controls for a COE must be inclusive enough to cover the threat model for the target dep-

loyments of systems built on the COE, but must not be so onerous to render the system unusable.

We consider security requirements, tradeoffs, and solu-tions for the different system layers of a COE, including 1) the network, 2) computational platforms and 3) the common software infrastructure consisting of a SOA stack, common services, and applications. We explore ways to provide the key aspects of system security: confidentiality, integrity, and availability. In addition to securing the SOA stack for infor-mation assurance, it is important to ensure the continued operation of the COE and of critical services and applica-tions. Therefore, we also discuss SOA design considerations for survivability, and other cross cutting user experience or business focused aspects such as transparency, flexibility, specificity, reuse, and assurance.

Our discussions of security along the COE layers and cross-cutting concerns are motivated by existing standards and technologies currently used to address security needs, albeit often poorly used. For example, many existing off-the-shelf SOA infrastructures include security mechanisms, but they are surprisingly easy to misconfigure [1] and limited in their scope. Authentication and authorization services are also commonly included (or at least provided as interfaces) in off-the-shelf SOA stacks, but advanced security concepts such as Multi-Level Security (MLS), cross-domain informa-tion exchange, and survivability capabilities are not yet as widely adopted. We pay particular attention to technologies supporting MLS, cross-domain information exchange and survivability as these areas of interest span our decomposi-tions of systems and address cross-cutting concerns. Fur-thermore, these functions are key to the adoption of SOA infrastructure in COEs for domains with mission- or safety-critical systems, such as the military, intelligence communi-ty, and multi-organizational collaboration. Some of these technologies are reasonably mature, but might be limited in their scope. Others are less well developed, but might pro-vide more promise than reality.

The paper is structured as follows. Section II discusses security concerns for each layer in our system view decom-position of COEs. Section III describes several security stan-dards motivating the adoption of security technologies. Sec-tion IV presents technologies addressing the requirements, along with their advantages and limitations in the domains of COEs and cross-domain information exchange. Section V makes recommendations for a way forward and presents some concluding remarks.

Figure 1. HAIPE devices allow platforms in classified domains to communicate over untrusted networks.

HAIPEHAIPE Tunnel

HAIPEII. SYSTEM VIEW DECOMPOSITION In this section we discuss the decomposition of COE se-

curity concerns into issues concerning 1) the network, 2) computational platforms, and 3) the common software infra-structure.

A. Network Core Concerns COEs need to support distributed services and applica-

tions, spanning multiple network enclaves and communicat-ing over networks with varying classifications and security features, such as tactical radios and satellite links. The DoD Global Information Grid (GIG) assumes a paradigm where enclaves of different levels of criticality can plug into a common reliable communication infrastructure, i.e., a “black core”. COEs running in a black core paradigm must ensure end-to-end communication security themselves, without re-lying on the network over which they may not have control. Toward that end, enclaves with higher security requirements must use High Assurance Internet Protocol Encryptors (HAIPE), encryption devices conforming to the NSA speci-fied High Assurance Internet Protocol Interoperability Speci-fication, as their gateways to the outside network. Insertion of HAIPE devices should be transparent to the SOA stack hosting the application logic. If the service provider enclave and the service consumer enclave communicate over an un-trusted network, the HAIPE devices at these two enclaves must establish an a priori security association (e.g., a HAIPE tunnel), as shown in Figure 1, before the service consumer can interact with the service provider. Recently, NSA has published the IPsec Minimum Essential Interoperability Re-quirement (IPMEIR). IPMEIR compliant devices will re-place HAIPE devices in the future and will support IPV6, a newer version of Internet Key Exchange, and recommends the use of Elliptic Curve Cryptography.

B. Host (Computation) Platform Concerns One of the key requirements for platforms hosting COEs

is to enable access to information at the various levels of classification that it exists. The platform must provide autho-rization and access control with the following two essential features:

• The system must enforce restrictions on access to in-formation regardless of the actions of system users or administrators.

• The system must enforce restrictions on access with incredibly high reliability.

A brute force method for supplying these features is to have separate hardware (i.e., computers and networks) for each classification level of information. SIPRNet (for infor-mation up to the Secret level) and JWICS (for information up to Top Secret and SCI) are examples of this. Dedicated hardware solutions have the following drawbacks [25]:

• The need for separate computers to handle informa-tion at every level places a financial and logistic burden on organizations.

• Systems are shared by users, not all of whom have the same clearance levels.

• Switching between different physical computers se-verely degrades usability of the overall system.

Many environments that we envision using a COE would be affected by this. Any environment except the most re-source rich enterprise environment will have constraints on the number of computers and networks they can support. For example, vehicle environments are by their nature con-strained, and adding hardware (computers and radios) to only support additional classification levels comes with size, weight, and power implications. Likewise, dedicated hard-ware solutions limit the scalability of the resulting system, because each new classification of information, or use of the system in missions unanticipated at design time, implies a potentially costly and time consuming hardware modifica-tion. Any system that is involved in, or might be deployed in situations requiring, the collection, processing, and dissemi-nation of classified or higher information, motivates a re-quirement for some form of Multi-Level Security solution as part of a COE.

Multi-Level Security (MLS). MLS addresses the exis-tence of information at different levels of classification on a platform, implying limits on who can access it for what pur-poses or what resources can be shared across security do-mains. To some approximation, MLS is an enhanced version of access control with a focus on isolation, addressed partial-ly by authorization packages and by mechanisms such as Linux file protections. There are two benefits of MLS: 1. It allows users of a single computer to access all of the

domains they need. 2. MLS servers typically deal with consolidating data with-

in an enterprise. Rather than having one storage server for each domain, you can have a logically clustered MLS database that provides information only to the do-main that has the right to receive it.

The security challenges of MLS are more extreme than for simple access control because of the severity of informa-tion leakage. Organizations like the DoD, Intelligence Com-munity, and certain companies require a higher degree of information protection than simple access control can pro-vide and want to protect information (and restrict access) based on a set of strict rules associated with security classifi-cations and individual clearances allowing access to levels of information, e.g., Confidential, Secret, and Top Secret. Smith [25] provides a good overview of the MLS problem, motiva-tion, and issues.

Current MLS solutions are evaluated under the Common Criteria [4] and certified to an Evaluated Assurance Level (EAL). The amount of security provided by a system is cap-tured in its Protection Profile or Security Target against which a system is evaluated.

In addition, MLS systems are classified by the Protection Level (PL) they provide as defined in the Director of Central Intelligence Directive (DCID) 6/3 [7]. Cross Domain guards

that bridge one domain boundary, e.g., by going from JWICS to SIPRNet or going from SIPRNet to NIPRNet, are required to provide PL4 or above. Devices supporting a guard, e.g., HTTP proxies or ISSE proxy servers, need to provide PL3 or above. Finally, guards at domain boundaries, e.g., going from JWICS to NIPRNet, need to provide PL5.

MLS support is making its way into modern trusted op-erating systems (TOS), because of the emphasis on highly reliable restrictions enforced in the OS kernel, including the following:

• Green Hills Integrity-178B, which includes an op-tional ARINC-653 compliant partition scheduler, which supports MLS on a single processor. Integrity has been certified by the NSA-managed NIAP lab to EAL 6+1.

• Wind River VxWorks has also been certified to EAL 6+2 for MLS systems.

• LynuxWorks LynxSecure 3.0, which is a separation kernel and embedded hypervisor, provides support for MLS systems. LynxSecure is designed to be cer-tifiable to EAL 73.

• Solaris 10 with trusted extensions [10]. In addition to the above commercial OSes, there are a

few open source and openly available OSes that provide support for MLS, including the following:

• SE Linux has had MLS support since version 2.6.12 [12], [14] and has an active effort to achieve EAL 4+ certification4. However, unlike the three commercial products above, SE Linux does not employ a MILS-based (described below) approach to providing MLS capabilities. Instead it employs Mandatory Access Control (MAC) support in the operating system.

• FreeBSD also has Mandatory Access Control at its core. As part of its MAC capabilities, it provides an MLS module, which enables subjects (e.g., users, processes, or administrators) to be labeled with do-mains (e.g., representing a clearance level) and ob-jects (e.g., files) to be labeled with types representing security classifications. The operating system enforces fixed Bell-La Padula MAC rules (described in Section IV.B) [2].

Multiple Independent Levels of Security (MILS). MILS is a concept related to MLS. While MLS is a capability, i.e., support for information of different classification levels coexisting on a single system, MILS is an architecture or technique that can help achieve MLS. MILS partitions a sys-tem into separate virtual or physical sub-systems. Each parti-tion has separate processor, memory, and secondary storage resources, and there is strict control of information flow be-tween partitions.

1 Source is the Green Hills website, http://www.ghs.com/products/rtos/integrity.html 2 Source is the Wind River website, http://www.windriver.com/products/platforms/vxworks-mils/ 3 Source is the LynuxWorks website, http://www.lynuxworks.com/virtualization/hypervisor.php 4 Source is the Fedora website, http://fedoraproject.org/wiki/SELinux/MLS

Several of the systems above use MILS as a technique to support MLS, including the following.

• Green Hills Integrity-178B implements a MILS ar-chitecture with a separation kernel.

• Wind River’s VxWorks implements a MILS separa-tion kernel that partitions a single processor among multiple software components and employs secure inter-partition communication.

• Likewise, LynuxWorks LynxSecure is built upon a MILS architecture, utilizing a separation kernel that partitions data and resources in a system and strictly controls information flow between the partitions.

Key differences between separation kernels and hypervi-sors used by standard virtualization technologies, e.g., VM-ware workstation, are the small size of the hypervisor kernels (~10k vs. ~100k lines of code) and the certification and test-ing performed on the separation kernels, which is typically at the EAL7 level.

C. SOA Platform and Application Concerns In some sense, the SOA platform and application decom-

position level most readily utilizes Commercial off the Shelf (COTS) solutions for security concerns. For example, JBoss is one of the most widely adopted off-the-shelf and open-source SOA environments available today. JBoss includes the Java Authentication and Authorization Service (JAAS), which is an authentication and authorization framework inte-grated into the Java Runtime Environment (JRE). JAAS is an interface to access third party Authentication & Authoriza-tion services. The third party authentication module, e.g., a login module, is specified in a configuration file, while au-thorization rules are specified in another configuration file. JAAS provides services that will callback to an application to prompt for a username and password (or other credentials) and tests whether permission was granted.

As examples of third party authentication services that can be used with JAAS, OpenSSO and JBoss PicketLink are two Single Sign On (SSO) packages. SSO is an authentica-tion technique that authenticates a user once (e.g., with user-name and password, or with a certificate) and enables access for the duration of a session.

Authentication, such as provided by SSO, is only a ne-cessary pre-requisite for access control. It establishes the identity of a user by validating credentials. In addition, there also needs to be a set of access rules identifying the re-sources that a particular user is authorized to access. As an example, Unix operating systems authenticate username by virtue of logging in. A user can be identified by a number of attributes, including username and groups. Access control policies are then attached to files in terms of read, write, and execute access permissions. Additionally, policies can re-strict allowable behavior of processes by virtue of process control frameworks, e.g., SELinux.

While SOA is not equivalent to Web Services (WS), the two are often equated. WS includes several OASIS stan-dards, including WS-Security, WS-Trust, and WS-SecurityPolicy. JBossWS is a part of JBoss’s distribution that provides the JBoss AS with a Web Service stack, com-plete with WS-Security support. Two example authorization

packages for Web Service environments are Soutei and Pick-etLink. Soutei expresses access rules in Prolog, while Pick-etLink specifies access rules in XACML, an OASIS stan-dard, and implements WS-Trust support.

D. Cross-Cutting Aspects of Security Identifying, selecting, and designing core security fea-

tures for a COE needs to address the following three ac-cepted and widely referenced goals:

• Confidentiality (C) – Preventing leakage of informa-tion to unauthorized users.

• Integrity (I) – Preventing corruption of information and systems, i.e., ensuring that data or processes have not been compromised or altered inappropriate-ly.

• Availability (A) – Preventing loss of service or loss of access to information, i.e., ensuring that data and processing is available when it is needed.

The CIA requirements are well understood, and there are a number of documents that provide guiding principles for establishing security in a COE. In addition, security solutions for COEs should address the following cross-cutting con-cerns which reflect on the quality and value proposition of the security solution:

• Transparency: Clients and servers running within the COE should be shielded from much of the com-plexity underlying security operations. In a sense, transparency aligns with the basic “services” vision in that security should be provided, and clients should not have to know or care how those security services are provided.

• Flexibility: The COE should be able to balance the tradeoffs of the CIA goals of users and operational needs, which can sometimes come into conflict; and the COE should be able to provide comparable le-vels of security when used in tactical and enterprise environments.

• Specificity: Security in the COE should satisfy the specific guidelines or requirements of operational environments. For example, Certification and Ac-creditation (C&A) requirements, such as DIACAP and SP-800-53 (+53A), are relevant for specificity in DoD operational environments.

• Reuse: Security features of a COE should be able to be used in multiple domains or operational contexts. Solutions with reuse general have very clear descrip-tions, such as many mature COT solutions (JBoss, PicketLink, etc.) and are self-managed and configur-able.

• Assurance: This concern focuses on ensuring the se-curity solutions do what they claim to do (in terms of providing security guarantees). NIST risk-based management process and the Security Content Au-tomation Protocol (SCAP) are useful to assess this concern.

E. Survivability The security issues and techniques described so far in this

paper have focused on protection aspects, i.e., access control,

protection of integrity, and preventing leakage of (confiden-tiality) information. While these also provide protection against loss of availability, the loss of critical functionality in many systems is a significant danger. Systems are increa-singly deployed in hostile environments, such as disaster areas, areas of extreme temperatures, dirt, radiation, and pressure. Furthermore, computer-based systems have be-come attractive targets of adversaries who aim to benefit by subverting or disrupting the operation of such systems. Some of these adversaries are well-resourced and determined and therefore can launch sustained, staged attacks. Other adver-saries can be insiders, i.e., users with legitimate credentials who gain access to the system, but then engage in destructive or improper behavior.

There is significant risk to relying on protection mechan-isms alone in the security of a mission-critical system. The conflict between attackers and defense is stacked against the defense. An adversary needs to find only one flaw in a sys-tem to exploit, whereas the defense needs to identify and address as many as possible.5 A system that has a single vulnerability becomes completely unprotected to many at-tackers once the vulnerability is discovered, no matter how many protections against other vulnerabilities the system has.

To develop a truly robust mission-critical system, one must assume that attacks will happen and that they will suc-ceed. Even the most protected system is often susceptible to

• Insider attacks, i.e., situations in which a user, appli-cation, or process with the proper credentials goes rogue. There are many examples in which security breaches have been caused by individuals who have the proper credentials, and have been vetted by the proper process, but then—maliciously or inadver-tently—misuse that access.6

• Novel or zero-day attacks, i.e., attacks that have not been experienced before and therefore are not going to be caught by signature-detecting protection, like virus detection software.

• Sustained and staged attacks. Many deployed sys-tems will be exposed to well-resourced and deter-mined adversaries. These adversaries will launch sustained, staged attacks, and persist in attacking un-til they have penetrated a system.

As a result, future mission-critical systems will need to survive sustained attacks by sophisticated and well-motivated adversaries, something that is not achievable by the way available security solutions are currently applied to systems and networks [21]. Survivable systems combine the prin-ciples of security and fault tolerance—protecting to the ex-tent possible and adapting to survive successful attacks. In-

5 “We only need to be lucky once. You need to be lucky every time.” – The IRA to Margaret Thatcher, after a failed assassination attempt by bombing the Grand Hotel in Brighton on October 12, 1984. 6 The recent leak of classified documents to Wikileaks is alleged to have been perpetrated by an intelligence analyst who had legiti-mate access to classified documents, but misused that access by copying them to unsecure computers and passing the information to unauthorized persons.

corporating survivability into a system differs from simply incorporating security in the following ways:

• It assumes that some attacks will succeed, i.e., that not all attacks can be protected against, no matter how many protection mechanisms are deployed.

• It detects, responds, and recovers from the symptoms or effects of a successful attack, not just its signature or method of entry. To an approximation, a success-ful attack that has no adverse effect on a system’s confidentiality, integrity, or availability is not delete-rious.

• It balances the functional and security needs of a system. Excessive security can be as deleterious to the functionality of a system as an attack itself, if it uses too many resources, introduces too much over-head, or otherwise negatively impacts the usability of a system.7

• Incorporating survivability into a system differs from simply incorporating fault tolerance in the following ways:

• It removes the typical fault tolerance assumption that faults are independent and not correlated. In contrast, if there is an intelligent adversary behind an attack, attacks and faults are more likely to be correlated. In fact, some attacks could be launched not to compro-mise the system, but to probe the defenses to help the adversary select and launch destructive attacks.

• It does not rely on only redundancy and recovery. Identical replicas of functionality are going to all be compromised by a single attack without some kind of containment. Likewise, recovery is not going to be effective against sustained attacks—the recovered functionality will just be compromised again upon recovery.

Survivability concerns cross-cut the layers of the COE decomposition. Building survivability into common infra-structure requires a combination of the following survivabili-ty concepts [23], implemented in the proper combination and depth to fit the footprint of overhead and resources available in the target system platform:

• Protection, especially of single points of failure. • Difficult to penetrate barriers before key assets.

Physical protection is typically considered more se-cure and harder to circumvent than software protec-tion, so hardware protection, such as hardware fire-walls, secure NICs, and so forth should be placed at the entry points to critical system components [23]. Recently, we have been developing a software crumple zone capability that provides a layer of at-tack absorption to protect key assets [21].

• Redundancy and diversity. Redundancy and restart are core concepts for fault tolerance. When they are combined with diversity, so that replicas differ in

7 “The only truly secure system is one that is powered off, cast in a block of concrete and sealed in a lead-lined room with armed guards.” — Gene Spafford, Purdue University professor and com-puter security expert.

implementation language and are hosted on diverse OSes and platforms, it reduces the risk of common mode failures and common attacks.

• Defense in depth. The more obstacles that an adver-sary must face and the more layers of defense that an adversary must defeat, the more likely that one of the layers will stop the attack. Dynamic defense in depth, in which defenses are adaptive to learn and improve over time can raise the bar facing the attacker even further, as shown in Figure 2.

• Containment. The effects of attacks must be con-tained, as must the access of insiders, so that a single successful intrusion does not turn into multiple breaches.

• Unpredictable adaptive response. The system must adapt to survive. Traditional systems, and too many existing legacy systems, are brittle and inflexible. If provided enough resources, correct input, and a fa-vorable environment, they work. If not, they break, sometimes catastrophically. In contrast, an adaptive system has an operating range and can gracefully degrade in non-optimal conditions, as shown in Fig-ure 3. The goal is to continue operation, even if in a degraded mode. However, if adaptive responses are predictable, they can be exploited by adversaries, e.g., to trick a critical system into degrading its per-formance. Therefore, the adaptive response must be unpredictable to the attacker. This could be as sim-ple as varying the number and placement of replicas, the failover pattern, and so forth.

Figure 2. Dynamic defense in depth presents dynamic layers of protection against adversaries.

(a) A non-adaptive system fails in degraded conditions

(b) An adaptive system grace-fully degrades.

Figure 3. Adaptive response makes a system more robust in a wider range of dynamic deployment conditions.

“Broken” “Works”“Working Range”

Specific characteristics of modern operating environ-ments, such as SOA, add to the challenge of securing them completely, including their dynamism, loose-coupling, and novel messaging and interaction patterns. Moreover, current SOA environments lack the level of sophistication in protec-tion, detection, and adaptation capabilities needed to survive against motivated, well-resourced, and determined adversa-ries. As a result, current service-oriented systems are at sig-nificant risk of corruption, loss of service, and maliciously initiated leakage of information.

Survivability concepts work with, utilize, and augment existing security standards, protection mechanisms, and fault tolerance approaches. A combination of these concepts, en-hanced with the advanced techniques described above, which are emerging from DARPA and AFRL sponsored research can provide adaptive survivability to a COE. However, the levels, techniques, and combinations need to be chosen to match the level of protection needed and the resource foot-print and overhead cost that the system deployment can af-ford.

III. SECURITY STANDARDS AND GUIDELINES Although we list assurance as one of several concerns as-

sociated with cross-cutting aspects of security, it could be argued that assurance is the most important for individual deployments. Users want to know that security solutions will operate as advertised. Ideally, a COE would offer sufficient security infrastructure and services to satisfy all guidelines, if not specifically by the infrastructure, then by the applications and services built within and upon the COE. The security techniques and approaches described in this paper are under consideration to be included in a COE to satisfy the IA guidelines.

The National Institute of Standards and Technology (NIST) published a comprehensive set of engineering prin-ciples for providing security in IT systems [26], which pro-vided 33 principles in the following six categories:

• Security foundation – Security should be a founda-tional part of a security design and development.

• Risk based – Focus on reducing the risk of attack and compromise of a system.

• Ease of use – Strive for ease of use, upgrades, and portability.

• Increase resilience – Strive to make the target sys-tem more resilient to attacks.

• Reduce vulnerabilities – Minimize the aspects of system design and development that introduce vul-nerabilities.

• Design with network in mind – Expect systems to be distributed and develop security to address distri-buted aspects.

Another source for security guidelines is DODI Directive 8500.02, “Information Assurance (IA) Implementation” [6], which describes IA requirements in three Mission Catego-ries:

• Mission Category I – Systems handling vital infor-mation. Loss of integrity or availability of a Mission Category I system is unacceptable.

• Mission Category II – Systems handling information that is important to the support of operations. The loss of integrity is unacceptable, while the loss of availability is tolerable only for a short time.

• Mission Category III – Systems handling informa-tion necessary to conduct day-to-day business, but does not affect critical operations. The loss of integr-ity or availability is tolerable without significant im-pacts on critical operations.

While the guidelines above can help drive the creation of security solutions for a COE, the security features in a COE will need to be validated, certified, and accredited against the standards adopted and accepted by the deploying agency or organization. NIST’s SCAP provides a suite of standards (version 1.1 consists of seven component standards) that can be used to validate security solutions. SCAP supports auto-mated vulnerability and patch checking, technical control compliance activities, and security measurement [24].

Similarly, the DoD Information Assurance Certification and Accreditation Process (DIACAP) specification estab-lishes the process for Certification and Accreditation (C&A) of the information assurance of a system [9]. C&A through a documented process such as DIACAP is necessary prior to deployment of a COE that includes information assurance.

There are quite a few security standards that have been established for SOA, Web Services, and related environ-ments. Unfortunately, these standards do not provide a com-plete security solution, so much as a protocol construction kit with little guidance on how to construct a completely secure system.

The Organization for the Advancement of Structured In-formation Standards (OASIS) defines about a dozen security related standards for SOA and Web Services, including the eXtensible Access Control Markup Language (XACML) [20], Security Assertion Markup Language (SAML) [16], Web Services Security [17], WS-SecurityPolicy [18], and WS-Trust [19].

The Telecommunication Standardization Sector (ITU-T) has produced one of the most widely used public key infra-structure (PKI) standards for single sign-on and identity management, X.509 Certificates. X.509 specifies standards for certificates and certificate management.

The Internet Engineering Task Force (IETF) has estab-lished two of the most widely used standards for application-level encryption for secure transport of information: Trans-port Layer Security (TLS) and Secure Sockets Layer (SSL).

IV. TECHNOLOGY TO ADDRESS REQUIREMENTS In this section, we discuss two emerging technologies

that are promising for addressing the various technology concerns described earlier in this paper and for use to pro-vide security in a COE:

• NSA’s High Assurance Platform (HAP) program which aims to provide a comprehensive solution to the security concerns we have identified for SOA-based COEs. The HAP program is addressing the MLS, MILS, and Cross Domain challenges, with the ultimate goal of exploiting modern virtualization,

Figure 4. HAP enables multiple windows, each representing a separate security domain, to be displayed on the same worksta-tion. Classification levels are simulated.

UNCLASS

S//Releasable

S//NOFORNsoftware separation and software enabled cross do-main solutions to enable analysts to access informa-tion and systems at multiple classification levels from a single workstation.

• Additional Cross Domain Solutions enabling infor-mation exchange, policy management, and identity management across security domains, effectively ba-lancing the tension between need to know and need to protect.

A. High Assurance Platform Traditionally, information analysts have had the creden-

tials to access multiple domains, each at a different classifi-cation level, but historically each domain is separated physi-cally via hardware solutions. An analyst has to move to a different workstation and login to the new domain, which is separated from the other domains by being hosted on a dif-ferent computer and separate network, and the existence of a hardware device, a guard, certified and accredited to enable transfer of information between domains.

The purpose of HAP is to move from the current state of the practice to one in which an analyst can have multiple domains displayed on a single workstation, each in its own window, as shown in Figure 4 [11].

Displaying multiple domains on a single workstation is a significant step beyond the current state of the practice, be-cause of the reduction in the amount of equipment and the inconvenience of analysts having to move from workstation to workstation. It requires separation of the domains to be supported and enforced by separate secure virtual machines (VMs) or separation kernels in the operating system. How-ever, the goals of HAP are to move beyond simply display-ing the different domains on a single workstation, to allow the movement of information between domains from the same workstation, such as copy-and-paste or drag-and-drop between windows on the same workstation.

The capabilities provided by VMs and operating systems are not sufficient to support such movement between win-dows (and domains). The movement of information between domains is still governed by guards, which are typically hardware devices certified and accredited for specific inte-ractions between specific domains. The type of sharing that HAP envisions, i.e., to support information movement be-tween domains via drag-and-drop for example, would re-quire moving the guard functionality into something like a hypervisor that resides on the workstation, but in a position to mediate and filter all of the interaction between the virtual machines in a certified and accredited manner.

At this point, HAP Release 1 is available in at least two products:

• The Dell | INTEGRITY Secure Consolidated Client Solution, which is built on top of the INTEGRITY-178B separation kernel.

• The General Dynamics High Assurance Platform Workstation (HAPWS), which utilizes hardware-assisted NSA-certified VM separation and a har-dened Hypervisor [11].

HAP Release 1 supports single level separation, i.e., Top Secret and Secret or Secret and Unclassified; hardware-

assisted attestation, i.e., integrity checking of the platform before network access is allowed; one local user per HAP workstation; and simultaneous display, but no sharing, of information from different domains.

HAP Release 2 is planned to provide, among other things, two-domain separation supporting Unclassified through Top Secret; and tactical server platforms.

HAP Release 3 is also planned to have significantly greater capabilities, including cross domain collaboration; information sharing, including low-to-high cut-and-paste; and SSO, enabling a user to sign into all of his/her domains with one login screen.

The information about what is expected to be in Release 2 and Release 3 is obtained from [8], which provides a good roadmap of HAP capabilities and timeline for release availa-bility.

The COE that we envision is intended for use with a va-riety of environments, platforms, and users, not just Intelli-gence Community (IC) analysts, so it is important to consid-er the uses of HAP. The Release 1 version of HAP is heavily focused on user interfaces for visualization of multiple do-mains, which might be important for human-in-the-loop ap-plications requiring information from multiple domains to be displayed simultaneously. These applications could include command and control, search and rescue, disaster response, situation assessment, planning, and so forth. The focus on multiple user interfaces might be less important for embed-ded, tactical, unmanned, and autonomous (i.e., no human-in-the-loop) applications, for which display of information would be less important than fusing, correlating, or acting upon information from multiple domains.

The following systems are similar to HAP in both goals and instantiations:

• NetTop – In NetTop, the NSA developed a system to run multiple VMs on a SELinux machine, with SE-Linux providing access control and each VM representing a separate domain [15]. NetTop has been instantiated in products by Hewlett-Packard and Trusted Computer Solutions [13], [28].

• DODIIS Trusted Workstation – The DTW is an US Air Force Research Laboratory (AFRL) sponsored program that runs multiple security domains on a single computer. There are at least two instantiations of DTW in commercial products. Sun has a version

Figure 5. Non-hierarchical domains present problems for cross domain solutions.

built on Trusted Solaris [27] and Cubix makes a high-performance version for 3D graphics called La-serSystem-SABER [5], also developed on Trusted Solaris.

B. Cross Domain Solutions and Services One of the aspects addressed by HAP is cross domain in-

formation sharing, the movement of information between security domains. Cross domain information sharing is en-forced by Cross Domain Solutions (CDS), which are ap-proved and trusted data flows implemented between two or more domains. Each of these is traditionally designed, certi-fied, and accredited on a case-by-case basis, and enforced by a guard. Guards are dedicated hardware devices that filter cross-domain traffic and enforce a set of specific rules go-verning cross-domain flows between two or more domains. Although a guard is only part of the CDS, i.e., the enforce-ment part, the two terms are frequently used synonymously.

Cross domain information transfer is increasingly the subject of investigation, research, and development due to an awareness that getting information into the hands of first responders, law enforcement, soldiers, commanders, and analysts can be the difference between mission success and failure. Accordingly, cross domain information sharing is frequently described as balancing the “need to share” with the “need to protect” information.

Cross domain information sharing is governed by specif-ic, rigid rules, such as Bell-La Padula [2], which defines the following two Mandatory Access Control rules:

• No read-up, users at a given security level cannot read information at a higher security level.

• No write-down, users at a given security level cannot write information into a lower security level.

The BIBA model [3] defines rules that ensure preserva-tion of data integrity. While both models provide rigorous information assurance controls, they fall short of providing realistic control in at least a few ways:

• They only work well in strictly hierarchical security domains. Disallowed data transfers can be more dif-ficult to control in non-hierarchical domains. As an example, consider Figure 5 in which Domain B is not allowed to move information to Domain C, but both can move information back and forth with Do-main A. Domain B risks leakage of its information from Domain A to C.

• They don’t handle the situation in which a high do-main contains information that can be shared with a lower domain, but is classified at the high level by default of being in the high domain.

• They don’t address covert channels, in which infor-mation is moved through means that are not subject to access control rules.

V. CONCLUSIONS AND RECOMMENDATIONS FOR STEPS FORWARD

In designing a COE targeted toward distributed tactical and enterprise platforms, one would hope, and perhaps rea-sonably expect, to be able to acquire, integrate, and adapt

any of a number of off-the-shelf security solutions, to pro-vide the COE’s security features. Furthermore, it is reasona-ble to expect that basing the COE on standards-based, com-modity, and off-the-shelf components—IP-based networks, x86-based processors, SOA-based software infrastructure—would facilitate the ready adoption of a rich variety of securi-ty solutions associated with each layer of components.

However, our investigation—as part of defining a COE and as part of creating survivable service-oriented infrastruc-ture—has identified significant problems with these assump-tions [1], [21]:

• With a proliferation of security standards, features, and technologies, properly combining and configur-ing security features to provide the needed protec-tion becomes a challenge. Improperly configured se-curity features can cause two major problems in software systems. First, they can actually introduce additional vulnerabilities. For example, the introduc-tion of authentication features without the appropri-ate protection (e.g., encryption and protected sto-rage) of the authentication credentials can open a system up to new avenues for insider attacks and at-tack propagation. Second, improperly applied securi-ty features can provide the false illusion of total se-curity, i.e., users believe that the security features protect them and let down their guard, when in actu-ality the system exposes the users to significant vul-nerabilities.

• The adoption and application of security features adds to the overhead, reduces the performance, and otherwise uses resources that, while plentiful in some environments (such as enterprise systems) are constrained and scarce in other environments (such as tactical, embedded, and handheld systems). This means that the selection and application of powerful security solutions can inadvertently result in self-denial-of-service, e.g., less access to information by users, longer latencies, fewer functional features, and more cost, weight, and equipment.

Both of these present challenges for selecting and provid-ing security as part of the COE. In the short run, it means that the selection of security features must include configura-tion help, patterns of use, and validation of the levels of pro-tection provided. Assessing the strength of security and in-

formation assurance is a difficult challenge and an area of ongoing research [22]. In the long run, it means that the cur-rent COE development goals should be aligned with research efforts, such as HAP. If HAP attains its stated goals and can accommodate tactical environments, HAP version 3 will offer a prudent basis for future COEs.

The COE goal of promoting reuse and reducing the amount of special purpose, stove-piped solutions lines up with recent trends in the security community also. For exam-ple, in the CDS domain, guards have been typically devel-oped, certified, and accredited to enforce information flow on one point-to-point connection, resulting in a proliferation of guards, with little or no reuse of guard technology..

This has led to ongoing research in CDSs that leverage modern software engineering concepts such as SOA; that support multi-domain and non-hierarchical domain relation-ships; and that handle policies and identities across domain boundaries. Another current area of research is software guards, i.e., embedding software-only guards into platform infrastructure, such as hypervisors. Since all information that is exchanged between domains must go through the infra-structure, it can be mediated by the guards. Progress in these areas should greatly benefit the use of CDS in COEs.

Many of the topics discussed in this paper are applicable to secure cloud computting, often viewed as complementary to SOA technology. One of the distinct features of cloud computing is the dynamic reuse of common hardware. This provides the need and opportunity for the development of COEs; robust MLS and MILS technologies to manage access to sensitive data on shared, distributed resources; and soft-ware guards to manage the flow of sensitive information on commodity hardware. These are analogous to the needs for SOA technologies, but without dedicated hardware. Unlike for SOA, there are few security standards or standard prac-tices for cloud computing and the development of such stan-dards will be ongoing as the use-cases for cloud computing evolves.

Lastly, as mentioned in Section III, the choices of securi-ty solutions and approaches for a COE are subject to C&A requirements before the COE can be deployed and used in certain environments. This is yet another motivation for lin-ing up with existing thrusts, reusing components and solu-tions being developed with similar goals in mind. We expect that different deployments will have different C&A require-ments, e.g., the DoD and IC. Leveraging the C&A that is part of the development of solutions such as HAP and CDS will shorten the C&A path for a COE.

REFERENCES [1] Michael Atighetchi, Partha Pal, Andrew Gronosky.

“Understanding the Vulnerabilities of a SOA Platform - A Case Study,” The 9th IEEE International Symposium on Network Computing and Applications (IEEE NCA10), 2010, Cambridge, MA.

[2] David Bell, Leonard La Padula, “Secure Computer Systems: Mathematical Foundations,” MITRE Corporation, March 1, 1973.

http://www.albany.edu/acc/courses/ia/classics/belllapadula1.pdf.

[3] Biba, K. J. "Integrity Considerations for Secure Computer Systems", MTR-3153, The Mitre Corpora-tion, April 1977.

[4] The Common Criteria Portal. http://www.commoncriteriaportal.org/

[5] CUBIX, “LaserSystem-SABER (formerly known as DODIIS Trusted Workstation),” Retrieved from http://www.cubix.com/content/lasersystem-saber-formerly-known-dodiis-trusted-workstation on Janu-ary 6, 2011.

[6] Department of Defense Instruction, Number 8500.2, “Information Assurance (IA) Implementation,” Feb-ruary 6, 2003. http://www.dtic.mil/whs/directives/corres/pdf/850002p.pdf.

[7] Director of Central Intelligence. “Protecting Sensitive Compartmented Information Within Information Sys-tems.” Directive 6/3. Washington: DCID, June 5, 1999.

[8] Rob Dobry, “High Assurance Platform Challenges,” 3rd Annual Layered Assurance Workshop (LAW 2009), August 4-5, 2009, San Antonio, Texas.

[9] DoD Information Assurance Certification and Accre-ditation Process (DIACAP), Department of Defense Instruction Number 8510.01, November 28, 2007.

[10] Glenn Faden, “Comparing the Multilevel Security Policies of the Solaris Trusted Extensions and Red Hat Enterprise Linux Systems,” Oracle BigAdmin System Administration Portal, February 2007. http://www.sun.com/bigadmin/features/hub_articles/mls_trusted_exts.jsp.

[11] General Dynamics, “High Assurance Platform Workstation,” Retrieved from http://www.gdc4s.com/documents/D-HAPWS-60207_p1.pdf on January 6, 2011.

[12] C. Hanson, “SELinux and MLS: Putting the Pieces Together,” Security Enhanced Linux Symposium, February 28-March 2, 2006, Baltimore, Maryland.

[13] Hewlett-Packard, “HP NetTop,” Retrieved from http://h71028.www7.hp.com/enterprise/cache/48852-0-0-225-121.html on January 6, 2011.

[14] B. Hicks, S. Rueda, L. St.Clair, T. Jaeger, P. McDa-niel, “A Logical Specification and Analysis for SE-Linux MLS Policy,” ACM Transactions on Informa-tion and System Security (TISSEC), Volume 13, Issue 3, July 2010.

[15] R. Meushaw, D. Simard, “NetTop, Commercial Technology in High Assurance Applications,” Tech Trend Notes, Volume 9, Edition 4, Fall 2000. http://www.vmware.com/pdf/TechTrendNotes.pdf.

[16] OASIS, Security Assertion Markup Language (SAML) 2.0, March 2005. http://saml.xml.org/saml-specifications

[17] OASIS, WS-Security 1.1, http://www.oasis-open.org/specs/#wssv1.1.

[18] OASIS, WS-SecurityPolicy 1.2, July 1, 2007. http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702/ws-securitypolicy-1.2-spec-os.pdf

[19] OASIS, WS-Trust 1.3, March 19, 2007. http://docs.oasis-open.org/ws-sx/ws-trust/200512/ws-trust-1.3-os.pdf

[20] OASIS, eXtensible Access Control Markup Lan-guage (XACML) Version 2.0, February 1, 2005. http://docs.oasis-open.org/xacml/2.0/access_control-xacml-2.0-core-spec-os.pdf.

[21] Partha Pal, Michael Atighetchi, Joseph Loyall, Charles Payne, Robert Hillman, “Advanced Protected Services - A Concept Paper on Survivable Service-Oriented Systems,” 1st IEEE International Workshop on Object/component/service-oriented Real-time Networked Ultra-dependable Systems, May 7, 2010, Carmona, Spain.

[22] Partha Pal, Rick Schantz, and Joseph Loyall, “Mid-dleware for Runtime Assessment of Information As-surance,” The ACM/IFIP/USENIX 11th International Middleware Conference (Middleware 2010), Nov 29- December 3, 2010, Bangalore, India.

[23] Partha Pal, Franklin Webber, Richard Schantz, “The DPASA Survivable JBI- A High-Water Mark in In-trusion-Tolerant Systems,” EuroSys Workshop on

Recent Advances in Intrusion-Tolerant Systems, March 23, 2007, Lisbon, Portugal.

[24] Stephen Quinn, David Waltermire, Christopher John-son, Karen Scarfone, John Banghart, “The Technical Specification for the Security Content Automation Protocol (SCAP): SCAP Version 1.1,” NIST Special Publication 800-126, May 2010.

[25] Rick Smith, “Authentication, Crypto, Information Security, and Life with Gadgets,” Cryptosmith, July 7, 2007, www.cryptosmith.com/archives/36.

[26] G. Stoneburner, C. Hayden, A. Feringa, “Engineering Principles for Information Technology Security (A Baseline for Achieving Security), Revision A,”. National Institute of Standards and Technology, June 2004.

[27] Sun Microsystems, “DTW – DODIIS Trusted Workstation, Intelligence Paradigm for the 21st Cen-tury,” Retrieved from http://www.sun-rays.org/lib/hardware/sunray/ds/go_DTW_cc.pdf on January 6, 2011.

[28] Trusted Computer Solutions, “SecureOffice Trusted Workstation on Linux,” Retrieved from http://www.trustedcs.com/products/TrustedWorkstationLinux.html on January 6, 2011.

[29] Robert Walker, “Common Operating Environment (COE) and Global Information Grid (GIG) Enterprise Services (GES),” Biometric Consortium Conference, September 22 - 24, 2003, Arlington, VA.