A Survey of Security Concepts for Common Operating Environments

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 loyments of systems built on the COE, but must not be so Service-Oriented Architecture (SOA), become the basis for onerous to render the system unusable. mission-critical systems, they must include security as a foun- We consider security requirements, tradeoffs, and solu- dational capability. This paper highlights security concepts tions for the different system layers of a COE, including 1) relevant to using SOA as a foundation for a Common Operat- the network, 2) computational platforms and 3) the common ing Environment (COE), i.e., a set of infrastructure and com- software infrastructure consisting of a SOA stack, common mon services for developing and executing applications across services, and applications. We explore ways to provide the multiple platforms. We present and motivate security needs, key aspects of system security: confidentiality, integrity, and tradeoffs, and solutions in the various layers of a SOA-based availability. In addition to securing the SOA stack for infor- COE, including 1) the network, 2) computational platforms, mation assurance, it is important to ensure the continued and 3) the common software infrastructure consisting of a SOA stack, common services, and applications. We also discuss operation of the COE and of critical services and applica- cross cutting aspects of security such as survivability, transpa- tions. Therefore, we also discuss SOA design considerations rency, flexibility, specificity, reuse, and assurance. We then for survivability, and other cross cutting user experience or explore security standards and requirements for mission- business focused aspects such as transparency, flexibility, critical systems developed on top of a SOA-based COE and specificity, reuse, and assurance. security technologies that are candidates for satisfying the re- Our discussions of security along the COE layers and quirements. The paper closes with a set of recommendations cross-cutting concerns are motivated by existing standards and steps forward for both research into and implementation and technologies currently used to address security needs, of security in a SOA-based COE. albeit often poorly used. For example, many existing off-the- shelf SOA infrastructures include security mechanisms, but Keywords: Security, Service-Oriented Architecture, Multi- they are surprisingly easy to misconfigure [1] and limited in Level Security, Cross Domain, Adaptive Survivability their scope. Authentication and authorization services are also commonly included (or at least provided as interfaces) I. INTRODUCTION in off-the-shelf SOA stacks, but advanced security concepts Building mission-critical systems as stove-piped systems such as Multi-Level Security (MLS), cross-domain informa- from the ground up has become untenable in terms of ex- tion exchange, and survivability capabilities are not yet as pense and maintainability. Stove-piped systems built from widely adopted. We pay particular attention to technologies scratch quickly become legacy and are outpaced by commer- supporting MLS, cross-domain information exchange and cial and off-the-shelf technology, which they cannot adopt survivability as these areas of interest span our decomposi- without major re-architecture and re-implementation. tions of systems and address cross-cutting concerns. Fur- This situation has become widely acknowledged by the thermore, these functions are key to the adoption of SOA industries and institutions that develop mission-critical sys- infrastructure in COEs for domains with mission- or safety- tems, including the US Department of Defense, the aero- critical systems, such as the military, intelligence communi- space industry, the health care, and financial industries. This ty, and multi-organizational collaboration. Some of these has led to the search for common operating environments technologies are reasonably mature, but might be limited in (COEs) and the adoption of modern software engineering their scope. Others are less well developed, but might pro- technologies, such as service-oriented architecture (SOA) vide more promise than reality. and SOA-based software stacks in building COEs. A COE is The paper is structured as follows. Section II discusses a set of infrastructure and common services for building and security concerns for each layer in our system view decom- executing applications on multiple platforms [29]. A COE position of COEs. Section III describes several security stan- enables suites of applications and systems for multiple do- dards motivating the adoption of security technologies. Sec- mains to be built with lower cost, improved code reuse, and tion IV presents technologies addressing the requirements, with improved portability and maintainability. along with their advantages and limitations in the domains of Security is a critical aspect of any COE. For a COE to be COEs and cross-domain information exchange. Section V useful, it must include the features necessary to ensure prop- makes recommendations for a way forward and presents er controls against unauthorized use and protection of critical some concluding remarks. services and data. The security controls for a COE must be inclusive enough to cover the threat model for the target dep-

II. SYSTEM VIEW DECOMPOSITION HAIPE HAIPE HAIPE Tunnel In this section we discuss the decomposition of COE security concerns into issues concerning 1) the network, 2) computational platforms, and 3) the common software infra- Figure 1. HAIPE devices allow platforms in classified domains to structure. communicate over untrusted networks. A. Network Core Concerns • Switching between different physical computers se- COEs need to support distributed services and applica- verely degrades usability of the overall system. tions, spanning multiple network enclaves and communicat- Many environments that we envision using a COE would ing over networks with varying classifications and security be affected by this. Any environment except the most re- features, such as tactical radios and satellite links. The DoD source rich enterprise environment will have constraints on Global Information Grid (GIG) assumes a paradigm where the number of computers and networks they can support. For enclaves of different levels of criticality can plug into a example, vehicle environments are by their nature con- common reliable communication infrastructure, i.e., a “black strained, and adding hardware (computers and radios) to only core”. COEs running in a black core paradigm must ensure support additional classification levels comes with size, end-to-end communication security themselves, without re- weight, and power implications. Likewise, dedicated hard- lying on the network over which they may not have control. ware solutions limit the scalability of the resulting system, Toward that end, enclaves with higher security requirements because each new classification of information, or use of the must use High Assurance Internet Protocol Encryptors system in missions unanticipated at design time, implies a (HAIPE), encryption devices conforming to the NSA speci- potentially costly and time consuming hardware modifica- fied High Assurance Internet Protocol Interoperability Speci- tion. Any system that is involved in, or might be deployed in fication, as their gateways to the outside network. Insertion situations requiring, the collection, processing, and dissemi- of HAIPE devices should be transparent to the SOA stack nation of classified or higher information, motivates a re- hosting the application logic. If the service provider enclave quirement for some form of Multi-Level Security solution as and the service consumer enclave communicate over an un- part of a COE. trusted network, the HAIPE devices at these two enclaves Multi-Level Security (MLS). MLS addresses the exis- must establish an a priori security association (e.g., a HAIPE tence of information at different levels of classification on a tunnel), as shown in Figure 1, before the service consumer platform, implying limits on who can access it for what pur- can interact with the service provider. Recently, NSA has poses or what resources can be shared across security do- published the IPsec Minimum Essential Interoperability Re- mains. To some approximation, MLS is an enhanced version quirement (IPMEIR). IPMEIR compliant devices will re- of access control with a focus on isolation, addressed partial- place HAIPE devices in the future and will support IPV6, a ly by authorization packages and by mechanisms such as newer version of Internet Key Exchange, and recommends Linux file protections. There are two benefits of MLS: the use of Elliptic Curve Cryptography. 1. It allows users of a single computer to access all of the domains they need. B. Host (Computation) Platform Concerns 2. MLS servers typically deal with consolidating data with- One of the key requirements for platforms hosting COEs in an enterprise. Rather than having one storage server is to enable access to information at the various levels of for each domain, you can have a logically clustered classification that it exists. The platform must provide autho- MLS database that provides information only to the do- rization and access control with the following two essential main that has the right to receive it. features: The security challenges of MLS are more extreme than • The system must enforce restrictions on access to infor simple access control because of the severity of informa- formation regardless of the actions of system users tion leakage. Organizations like the DoD, Intelligence Com- or administrators. munity, and certain companies require a higher degree of • The system must enforce restrictions on access with information protection than simple access control can pro- incredibly high reliability. vide and want to protect information (and restrict access) A brute force method for supplying these features is to based on a set of strict rules associated with security classifi- have separate hardware (i.e., computers and networks) for cations and individual clearances allowing access to levels of each classification level of information. SIPRNet (for infor- information, e.g., Confidential, Secret, and Top Secret. Smith mation up to the Secret level) and JWICS (for information [25] provides a good overview of the MLS problem, motiva- up to Top Secret and SCI) are examples of this. Dedicated tion, and issues. hardware solutions have the following drawbacks [25]: Current MLS solutions are evaluated under the Common • The need for separate computers to handle informa- Criteria [4] and certified to an Evaluated Assurance Level tion at every level places a financial and logistic (EAL). The amount of security provided by a system is cap- burden on organizations. tured in its Protection Profile or Security Target against • Systems are shared by users, not all of whom have which a system is evaluated. the same clearance levels. 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 Several of the systems above use MILS as a technique to to SIPRNet or going from SIPRNet to NIPRNet, are required support MLS, including the following. to provide PL4 or above. Devices supporting a guard, e.g., • Green Hills Integrity-178B implements a MILS ar- HTTP proxies or ISSE proxy servers, need to provide PL3 or chitecture with a separation kernel. above. Finally, guards at domain boundaries, e.g., going • Wind River’s VxWorks implements a MILS separa- from JWICS to NIPRNet, need to provide PL5. tion kernel that partitions a single processor among MLS support is making its way into modern trusted op- multiple software components and employs secure erating systems (TOS), because of the emphasis on highly inter-partition communication. reliable restrictions enforced in the OS kernel, including the • Likewise, LynuxWorks LynxSecure is built upon a following: MILS architecture, utilizing a separation kernel that • Green Hills Integrity-178B, which includes an op- partitions data and resources in a system and strictly tional ARINC-653 compliant partition scheduler, controls information flow between the partitions. which supports MLS on a single processor. Integrity Key differences between separation kernels and hypervi- has been certified by the NSA-managed NIAP lab to sors used by standard virtualization technologies, e.g., VM- 1 EAL 6+ . ware workstation, are the small size of the hypervisor kernels • Wind River VxWorks has also been certified to EAL (~10k vs. ~100k lines of code) and the certification and test- 6+2 for MLS systems. ing performed on the separation kernels, which is typically at • LynuxWorks LynxSecure 3.0, which is a separation the EAL7 level. kernel and embedded hypervisor, provides support for MLS systems. LynxSecure is designed to be cer- C. SOA Platform and Application Concerns tifiable to EAL 73. In some sense, the SOA platform and application decom- • Solaris 10 with trusted extensions [10]. position level most readily utilizes Commercial off the Shelf In addition to the above commercial OSes, there are a (COTS) solutions for security concerns. For example, JBoss few open source and openly available OSes that provide is one of the most widely adopted off-the-shelf and open- support for MLS, including the following: source SOA environments available today. JBoss includes • SE Linux has had MLS support since version 2.6.12 the Java Authentication and Authorization Service (JAAS), [12], [14] and has an active effort to achieve EAL 4+ which is an authentication and authorization framework inte- certification4. However, unlike the three commercial grated into the Java Runtime Environment (JRE). JAAS is an products above, SE Linux does not employ a MILS- interface to access third party Authentication & Authoriza- based (described below) approach to providing MLS tion services. The third party authentication module, e.g., a capabilities. Instead it employs Mandatory Access login module, is specified in a configuration file, while au- Control (MAC) support in the operating system. thorization rules are specified in another configuration file. • FreeBSD also has Mandatory Access Control at its JAAS provides services that will callback to an application core. As part of its MAC capabilities, it provides an to prompt for a username and password (or other credentials) MLS module, which enables subjects (e.g., users, and tests whether permission was granted. processes, or administrators) to be labeled with do- As examples of third party authentication services that mains (e.g., representing a clearance level) and ob- can be used with JAAS, OpenSSO and JBoss PicketLink are jects (e.g., files) to be labeled with types two Single Sign On (SSO) packages. SSO is an authentica- representing security classifications. The operating tion technique that authenticates a user once (e.g., with user- system enforces fixed Bell-La Padula MAC rules name and password, or with a certificate) and enables access (described in Section IV.B) [2]. for the duration of a session. Multiple Independent Levels of Security (MILS). MILS Authentication, such as provided by SSO, is only a ne- is a concept related to MLS. While MLS is a capability, i.e., cessary pre-requisite for access control. It establishes the support for information of different classification levels identity of a user by validating credentials. In addition, there coexisting on a single system, MILS is an architecture or also needs to be a set of access rules identifying the re- technique that can help achieve MLS. MILS partitions a sys- sources that a particular user is authorized to access. As an tem into separate virtual or physical sub-systems. Each parti- example, Unix operating systems authenticate username by tion has separate processor, memory, and secondary storage virtue of logging in. A user can be identified by a number of resources, and there is strict control of information flow be- attributes, including username and groups. Access control tween partitions. policies are then attached to files in terms of read, write, and execute access permissions. Additionally, policies can re-

1 strict allowable behavior of processes by virtue of process Source is the Green Hills website, control frameworks, e.g., SELinux. http://www.ghs.com/products/rtos/integrity.html While SOA is not equivalent to Web Services (WS), the 2 Source is the Wind River website, two are often equated. WS includes several OASIS stan- http://www.windriver.com/products/platforms/vxworks-mils/ 3 Source is the LynuxWorks website, dards, including WS-Security, WS-Trust, and WS- http://www.lynuxworks.com/virtualization/hypervisor.php SecurityPolicy. JBossWS is a part of JBoss’s distribution 4 Source is the Fedora website, that provides the JBoss AS with a Web Service stack, com- http://fedoraproject.org/wiki/SELinux/MLS plete with WS-Security support. Two example authorization

packages for Web Service environments are Soutei and Pick- protection of integrity, and preventing leakage of (confiden- etLink. Soutei expresses access rules in Prolog, while Pick- tiality) information. While these also provide protection etLink specifies access rules in XACML, an OASIS stan- against loss of availability, the loss of critical functionality in dard, and implements WS-Trust support. many systems is a significant danger. Systems are increasingly deployed in hostile environments, such as disaster D. Cross-Cutting Aspects of Security areas, areas of extreme temperatures, dirt, radiation, and Identifying, selecting, and designing core security fea- pressure. Furthermore, computer-based systems have be- tures for a COE needs to address the following three ac- come attractive targets of adversaries who aim to benefit by cepted and widely referenced goals: subverting or disrupting the operation of such systems. Some • Confidentiality (C) – Preventing leakage of informa- of these adversaries are well-resourced and determined and tion to unauthorized users. therefore can launch sustained, staged attacks. Other adver- • Integrity (I) – Preventing corruption of information saries can be insiders, i.e., users with legitimate credentials and systems, i.e., ensuring that data or processes who gain access to the system, but then engage in destructive have not been compromised or altered inappropriate- or improper behavior. ly. There is significant risk to relying on protection mechan- • Availability (A) – Preventing loss of service or loss isms alone in the security of a mission-critical system. The of access to information, i.e., ensuring that data and conflict between attackers and defense is stacked against the processing is available when it is needed. defense. An adversary needs to find only one flaw in a sys- The CIA requirements are well understood, and there are tem to exploit, whereas the defense needs to identify and a number of documents that provide guiding principles for address as many as possible.5 A system that has a single establishing security in a COE. In addition, security solutions vulnerability becomes completely unprotected to many at- for COEs should address the following cross-cutting con- tackers once the vulnerability is discovered, no matter how cerns which reflect on the quality and value proposition of many protections against other vulnerabilities the system has. the security solution: To develop a truly robust mission-critical system, one • Transparency: Clients and servers running within must assume that attacks will happen and that they will suc- the COE should be shielded from much of the com- ceed. Even the most protected system is often susceptible to plexity underlying security operations. In a sense, • Insider attacks, i.e., situations in which a user, appli- transparency aligns with the basic “services” vision cation, or process with the proper credentials goes in that security should be provided, and clients rogue. There are many examples in which security should not have to know or care how those security breaches have been caused by individuals who have services are provided. the proper credentials, and have been vetted by the • Flexibility: The COE should be able to balance the proper process, but then—maliciously or inadver- 6 tradeoffs of the CIA goals of users and operational tently—misuse that access. needs, which can sometimes come into conflict; and • Novel or zero-day attacks, i.e., attacks that have not the COE should be able to provide comparable le- been experienced before and therefore are not going vels of security when used in tactical and enterprise to be caught by signature-detecting protection, like environments. virus detection software. • Specificity: Security in the COE should satisfy the • Sustained and staged attacks. Many deployed sys- specific guidelines or requirements of operational tems will be exposed to well-resourced and deter- environments. For example, Certification and Ac- mined adversaries. These adversaries will launch creditation (C&A) requirements, such as DIACAP sustained, staged attacks, and persist in attacking un- and SP-800-53 (+53A), are relevant for specificity in til they have penetrated a system. DoD operational environments. As a result, future mission-critical systems will need to • Reuse: Security features of a COE should be able to survive sustained attacks by sophisticated and well-motivated be used in multiple domains or operational contexts. adversaries, something that is not achievable by the way Solutions with reuse general have very clear descrip- available security solutions are currently applied to systems tions, such as many mature COT solutions (JBoss, and networks [21]. Survivable systems combine the prin- PicketLink, etc.) and are self-managed and configur- ciples of security and fault tolerance—protecting to the ex- able. tent possible and adapting to survive successful attacks. In- • Assurance: This concern focuses on ensuring the security solutions do what they claim to do (in terms of 5 “We only need to be lucky once. You need to be lucky every providing security guarantees). NIST risk-based time.” – The IRA to Margaret Thatcher, after a failed assassination management process and the Security Content Au- attempt by bombing the Grand Hotel in Brighton on October 12, tomation Protocol (SCAP) are useful to assess this 1984. concern. 6 The recent leak of classified documents to Wikileaks is alleged to have been perpetrated by an intelligence analyst who had legiti- E. Survivability mate access to classified documents, but misused that access by The security issues and techniques described so far in this copying them to unsecure computers and passing the information paper have focused on protection aspects, i.e., access control, to unauthorized persons.

corporating survivability into a system differs from simply implementation language and are hosted on diverse incorporating security in the following ways: OSes and platforms, it reduces the risk of common • It assumes that some attacks will succeed, i.e., that mode failures and common attacks. not all attacks can be protected against, no matter • Defense in depth. The more obstacles that an adver- how many protection mechanisms are deployed. sary must face and the more layers of defense that an • It detects, responds, and recovers from the symptoms adversary must defeat, the more likely that one of the or effects of a successful attack, not just its signature layers will stop the attack. Dynamic defense in depth, or method of entry. To an approximation, a success- in which defenses are adaptive to learn and improve ful attack that has no adverse effect on a system’s over time can raise the bar facing the attacker even confidentiality, integrity, or availability is not delete- further, as shown in Figure 2. rious. • Containment. The effects of attacks must be con- • It balances the functional and security needs of a tained, as must the access of insiders, so that a single system. Excessive security can be as deleterious to successful intrusion does not turn into multiple the functionality of a system as an attack itself, if it breaches. uses too many resources, introduces too much over- • Unpredictable adaptive response. The system must head, or otherwise negatively impacts the usability adapt to survive. Traditional systems, and too many of a system.7 existing legacy systems, are brittle and inflexible. If • Incorporating survivability into a system differs from provided enough resources, correct input, and a fa- simply incorporating fault tolerance in the following vorable environment, they work. If not, they break, ways: sometimes catastrophically. In contrast, an adaptive • It removes the typical fault tolerance assumption that system has an operating range and can gracefully faults are independent and not correlated. In contrast, degrade in non-optimal conditions, as shown in Fig- if there is an intelligent adversary behind an attack, ure 3. The goal is to continue operation, even if in a attacks and faults are more likely to be correlated. In degraded mode. However, if adaptive responses are fact, some attacks could be launched not to compro- predictable, they can be exploited by adversaries, mise the system, but to probe the defenses to help e.g., to trick a critical system into degrading its per- the adversary select and launch destructive attacks. formance. Therefore, the adaptive response must be • It does not rely on only redundancy and recovery. unpredictable to the attacker. This could be as sim- Identical replicas of functionality are going to all be ple as varying the number and placement of replicas, compromised by a single attack without some kind the failover pattern, and so forth. 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 infrastructure requires a combination of the following survivability 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 secure and harder to circumvent than software protec- Figure 2. Dynamic defense in depth presents dynamic layers of protection against adversaries. 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 attack absorption to protect key assets [21]. “Broken” “Works” • Redundancy and diversity. Redundancy and restart “Working are core concepts for fault tolerance. When they are Range” combined with diversity, so that replicas differ in

(a) A non-adaptive system (b) An adaptive system grace- 7 “The only truly secure system is one that is powered off, cast in a fails in degraded conditions fully degrades. block of concrete and sealed in a lead-lined room with armed guards.” — Gene Spafford, Purdue University professor and com- Figure 3. Adaptive response makes a system more robust in a puter security expert. wider range of dynamic deployment conditions.

Specific characteristics of modern operating environ- • Mission Category II – Systems handling information ments, such as SOA, add to the challenge of securing them that is important to the support of operations. The completely, including their dynamism, loose-coupling, and loss of integrity is unacceptable, while the loss of novel messaging and interaction patterns. Moreover, current availability is tolerable only for a short time. SOA environments lack the level of sophistication in protec- • Mission Category III – Systems handling information, detection, and adaptation capabilities needed to survive tion necessary to conduct day-to-day business, but against motivated, well-resourced, and determined adversa- does not affect critical operations. The loss of integr- ries. As a result, current service-oriented systems are at sig- ity or availability is tolerable without significant im- nificant risk of corruption, loss of service, and maliciously pacts on critical operations. initiated leakage of information. While the guidelines above can help drive the creation of Survivability concepts work with, utilize, and augment security solutions for a COE, the security features in a COE existing security standards, protection mechanisms, and fault will need to be validated, certified, and accredited against the tolerance approaches. A combination of these concepts, en- standards adopted and accepted by the deploying agency or hanced with the advanced techniques described above, which organization. NIST’s SCAP provides a suite of standards are emerging from DARPA and AFRL sponsored research (version 1.1 consists of seven component standards) that can can provide adaptive survivability to a COE. However, the be used to validate security solutions. SCAP supports auto- levels, techniques, and combinations need to be chosen to mated vulnerability and patch checking, technical control match the level of protection needed and the resource foot- compliance activities, and security measurement [24]. print and overhead cost that the system deployment can af- Similarly, the DoD Information Assurance Certification ford. and Accreditation Process (DIACAP) specification establishes the process for Certification and Accreditation (C&A) III. SECURITY STANDARDS AND GUIDELINES of the information assurance of a system [9]. C&A through a Although we list assurance as one of several concerns as- documented process such as DIACAP is necessary prior to sociated with cross-cutting aspects of security, it could be deployment of a COE that includes information assurance. argued that assurance is the most important for individual There are quite a few security standards that have been deployments. Users want to know that security solutions will established for SOA, Web Services, and related environ- operate as advertised. Ideally, a COE would offer sufficient ments. Unfortunately, these standards do not provide a com- security infrastructure and services to satisfy all guidelines, if plete security solution, so much as a protocol construction kit not specifically by the infrastructure, then by the applications with little guidance on how to construct a completely secure and services built within and upon the COE. The security system. techniques and approaches described in this paper are under The Organization for the Advancement of Structured In- consideration to be included in a COE to satisfy the IA formation Standards (OASIS) defines about a dozen security guidelines. related standards for SOA and Web Services, including the The National Institute of Standards and Technology eXtensible Access Control Markup Language (XACML) (NIST) published a comprehensive set of engineering prin- [20], Security Assertion Markup Language (SAML) [16], ciples for providing security in IT systems [26], which pro- Web Services Security [17], WS-SecurityPolicy [18], and vided 33 principles in the following six categories: WS-Trust [19]. • Security foundation – Security should be a founda- The Telecommunication Standardization Sector (ITU-T) tional part of a security design and development. has produced one of the most widely used public key infra- • Risk based – Focus on reducing the risk of attack structure (PKI) standards for single sign-on and identity and compromise of a system. management, X.509 Certificates. X.509 specifies standards • Ease of use – Strive for ease of use, upgrades, and for certificates and certificate management. portability. The Internet Engineering Task Force (IETF) has estab- • Increase resilience – Strive to make the target sys- lished two of the most widely used standards for application- tem more resilient to attacks. level encryption for secure transport of information: Trans- • Reduce vulnerabilities – Minimize the aspects of port Layer Security (TLS) and Secure Sockets Layer (SSL). system design and development that introduce vul- IV. TECHNOLOGY TO ADDRESS REQUIREMENTS nerabilities. • Design with network in mind – Expect systems to be In this section, we discuss two emerging technologies distributed and develop security to address distri- that are promising for addressing the various technology buted aspects. concerns described earlier in this paper and for use to pro- Another source for security guidelines is DODI Directive vide security in a COE: 8500.02, “Information Assurance (IA) Implementation” [6], • NSA’s High Assurance Platform (HAP) program which describes IA requirements in three Mission Catego- which aims to provide a comprehensive solution to ries: the security concerns we have identified for SOA- • Mission Category I – Systems handling vital infor- based COEs. The HAP program is addressing the mation. Loss of integrity or availability of a Mission MLS, MILS, and Cross Domain challenges, with the Category I system is unacceptable. ultimate goal of exploiting modern virtualization,

software separation and software enabled cross do- S//NOFORN main solutions to enable analysts to access informa- UNCLASS tion and systems at multiple classification levels from a single workstation. • Additional Cross Domain Solutions enabling infor- S//Releasable mation exchange, policy management, and identity management across security domains, effectively balancing the tension between need to know and need to protect. A. High Assurance Platform Traditionally, information analysts have had the creden- Figure 4. HAP enables multiple windows, each representing a tials to access multiple domains, each at a different classifi- separate security domain, to be displayed on the same worksta- cation level, but historically each domain is separated physi- tion. Classification levels are simulated. cally via hardware solutions. An analyst has to move to a different workstation and login to the new domain, which is assisted attestation, i.e., integrity checking of the platform separated from the other domains by being hosted on a dif- before network access is allowed; one local user per HAP ferent computer and separate network, and the existence of a workstation; and simultaneous display, but no sharing, of hardware device, a guard, certified and accredited to enable information from different domains. transfer of information between domains. HAP Release 2 is planned to provide, among other The purpose of HAP is to move from the current state of things, two-domain separation supporting Unclassified the practice to one in which an analyst can have multiple through Top Secret; and tactical server platforms. domains displayed on a single workstation, each in its own HAP Release 3 is also planned to have significantly window, as shown in Figure 4 [11]. greater capabilities, including cross domain collaboration; Displaying multiple domains on a single workstation is a information sharing, including low-to-high cut-and-paste; significant step beyond the current state of the practice, be- and SSO, enabling a user to sign into all of his/her domains cause of the reduction in the amount of equipment and the with one login screen. inconvenience of analysts having to move from workstation The information about what is expected to be in Release to workstation. It requires separation of the domains to be 2 and Release 3 is obtained from [8], which provides a good supported and enforced by separate secure virtual machines roadmap of HAP capabilities and timeline for release availa- (VMs) or separation kernels in the operating system. How- bility. ever, the goals of HAP are to move beyond simply display- The COE that we envision is intended for use with a va- ing the different domains on a single workstation, to allow riety of environments, platforms, and users, not just Intelli- the movement of information between domains from the gence Community (IC) analysts, so it is important to consid- same workstation, such as copy-and-paste or drag-and-drop er the uses of HAP. The Release 1 version of HAP is heavily between windows on the same workstation. focused on user interfaces for visualization of multiple do- The capabilities provided by VMs and operating systems mains, which might be important for human-in-the-loop ap- are not sufficient to support such movement between win- plications requiring information from multiple domains to be dows (and domains). The movement of information between displayed simultaneously. These applications could include domains is still governed by guards, which are typically command and control, search and rescue, disaster response, hardware devices certified and accredited for specific inte- situation assessment, planning, and so forth. The focus on ractions between specific domains. The type of sharing that multiple user interfaces might be less important for embed- HAP envisions, i.e., to support information movement be- ded, tactical, unmanned, and autonomous (i.e., no human-in- tween domains via drag-and-drop for example, would re- the-loop) applications, for which display of information quire moving the guard functionality into something like a would be less important than fusing, correlating, or acting hypervisor that resides on the workstation, but in a position upon information from multiple domains. to mediate and filter all of the interaction between the virtual The following systems are similar to HAP in both goals and instantiations: machines in a certified and accredited manner. • At this point, HAP Release 1 is available in at least two NetTop – In NetTop, the NSA developed a system to products: run multiple VMs on a SELinux machine, with SE- • The Dell | INTEGRITY Secure Consolidated Client Linux providing access control and each VM Solution, which is built on top of the INTEGRITY- representing a separate domain [15]. NetTop has 178B separation kernel. been instantiated in products by Hewlett-Packard • and Trusted Computer Solutions [13], [28]. The General Dynamics High Assurance Platform • Workstation (HAPWS), which utilizes hardware- DODIIS Trusted Workstation – The DTW is an US assisted NSA-certified VM separation and a har- Air Force Research Laboratory (AFRL) sponsored dened Hypervisor [11]. program that runs multiple security domains on a HAP Release 1 supports single level separation, i.e., Top single computer. There are at least two instantiations Secret and Secret or Secret and Unclassified; hardware- of DTW in commercial products. Sun has a version

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 information sharing, the movement of information between security domains. Cross domain information sharing is enforced 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, certified, and accredited on a case-by-case basis, and enforced by Figure 5. Non-hierarchical domains present problems a guard. Guards are dedicated hardware devices that filter for cross domain solutions. cross-domain traffic and enforce a set of specific rules go- any of a number of off-the-shelf security solutions, to pro- verning cross-domain flows between two or more domains. vide the COE’s security features. Furthermore, it is reasona- Although a guard is only part of the CDS, i.e., the enforce- ble to expect that basing the COE on standards-based, com- ment part, the two terms are frequently used synonymously. modity, and off-the-shelf components—IP-based networks, Cross domain information transfer is increasingly the x86-based processors, SOA-based software infrastructure— subject of investigation, research, and development due to an would facilitate the ready adoption of a rich variety of securi- awareness that getting information into the hands of first ty solutions associated with each layer of components. responders, law enforcement, soldiers, commanders, and However, our investigation—as part of defining a COE analysts can be the difference between mission success and and as part of creating survivable service-oriented infrastruc- failure. Accordingly, cross domain information sharing is ture—has identified significant problems with these assump- frequently described as balancing the “need to share” with tions [1], [21]: the “need to protect” information. • With a proliferation of security standards, features, Cross domain information sharing is governed by specif- and technologies, properly combining and configur- ic, rigid rules, such as Bell-La Padula [2], which defines the ing security features to provide the needed protec- following two Mandatory Access Control rules: • tion becomes a challenge. Improperly configured se- No read-up, users at a given security level cannot curity features can cause two major problems in read information at a higher security level. software systems. First, they can actually introduce • No write-down, users at a given security level cannot additional vulnerabilities. For example, the introduc- write information into a lower security level. tion of authentication features without the appropri- The BIBA model [3] defines rules that ensure preserva- ate protection (e.g., encryption and protected sto- tion of data integrity. While both models provide rigorous rage) of the authentication credentials can open a information assurance controls, they fall short of providing system up to new avenues for insider attacks and at- realistic control in at least a few ways: tack propagation. Second, improperly applied securi- • They only work well in strictly hierarchical security ty features can provide the false illusion of total se- domains. Disallowed data transfers can be more dif- curity, i.e., users believe that the security features ficult to control in non-hierarchical domains. As an protect them and let down their guard, when in actu- example, consider Figure 5 in which Domain B is ality the system exposes the users to significant vul- not allowed to move information to Domain C, but nerabilities. both can move information back and forth with Do- • The adoption and application of security features main A. Domain B risks leakage of its information adds to the overhead, reduces the performance, and from Domain A to C. otherwise uses resources that, while plentiful in • They don’t handle the situation in which a high do- some environments (such as enterprise systems) are main contains information that can be shared with a constrained and scarce in other environments (such lower domain, but is classified at the high level by as tactical, embedded, and handheld systems). This default of being in the high domain. means that the selection and application of powerful • They don’t address covert channels, in which infor- security solutions can inadvertently result in self- mation is moved through means that are not subject denial-of-service, e.g., less access to information by to access control rules. users, longer latencies, fewer functional features, and more cost, weight, and equipment. V. CONCLUSIONS AND RECOMMENDATIONS FOR STEPS Both of these present challenges for selecting and provid- FORWARD ing security as part of the COE. In the short run, it means In designing a COE targeted toward distributed tactical that the selection of security features must include configura- and enterprise platforms, one would hope, and perhaps rea- tion help, patterns of use, and validation of the levels of pro- sonably expect, to be able to acquire, integrate, and adapt tection provided. Assessing the strength of security and in-

formation assurance is a difficult challenge and an area of http://www.albany.edu/acc/courses/ia/classics/belllap ongoing research [22]. In the long run, it means that the cur- adula1.pdf. rent COE development goals should be aligned with research [3] Biba, K. J. "Integrity Considerations for Secure efforts, such as HAP. If HAP attains its stated goals and can Computer Systems", MTR-3153, The Mitre Corpora- accommodate tactical environments, HAP version 3 will tion, April 1977. offer a prudent basis for future COEs. [4] The Common Criteria Portal. The COE goal of promoting reuse and reducing the http://www.commoncriteriaportal.org/ amount of special purpose, stove-piped solutions lines up [5] CUBIX, “LaserSystem-SABER (formerly known as with recent trends in the security community also. For exam- DODIIS Trusted Workstation),” Retrieved from ple, in the CDS domain, guards have been typically devel- http://www.cubix.com/content/lasersystem-saber- oped, certified, and accredited to enforce information flow on one point-to-point connection, resulting in a proliferation formerly-known-dodiis-trusted-workstation on Janu- of guards, with little or no reuse of guard technology.. ary 6, 2011. This has led to ongoing research in CDSs that leverage [6] Department of Defense Instruction, Number 8500.2, modern software engineering concepts such as SOA; that “Information Assurance (IA) Implementation,” Feb- support multi-domain and non-hierarchical domain relation- ruary 6, 2003. ships; and that handle policies and identities across domain http://www.dtic.mil/whs/directives/corres/pdf/850002 boundaries. Another current area of research is software p.pdf. guards, i.e., embedding software-only guards into platform [7] Director of Central Intelligence. “Protecting Sensitive infrastructure, such as hypervisors. Since all information that Compartmented Information Within Information Sys- is exchanged between domains must go through the infra- tems.” Directive 6/3. Washington: DCID, June 5, structure, it can be mediated by the guards. Progress in these 1999. areas should greatly benefit the use of CDS in COEs. [8] Rob Dobry, “High Assurance Platform Challenges,” Many of the topics discussed in this paper are applicable 3rd Annual Layered Assurance Workshop (LAW to secure cloud computting, often viewed as complementary 2009), August 4-5, 2009, San Antonio, Texas. to SOA technology. One of the distinct features of cloud [9] DoD Information Assurance Certification and Accre- computing is the dynamic reuse of common hardware. This ditation Process (DIACAP), Department of Defense provides the need and opportunity for the development of Instruction Number 8510.01, November 28, 2007. COEs; robust MLS and MILS technologies to manage access [10] Glenn Faden, “Comparing the Multilevel Security to sensitive data on shared, distributed resources; and soft- Policies of the Solaris Trusted Extensions and Red ware guards to manage the flow of sensitive information on commodity hardware. These are analogous to the needs for Hat Enterprise Linux Systems,” Oracle BigAdmin SOA technologies, but without dedicated hardware. Unlike System Administration Portal, February 2007. for SOA, there are few security standards or standard prac- http://www.sun.com/bigadmin/features/hub_articles/ tices for cloud computing and the development of such stan- mls_trusted_exts.jsp. dards will be ongoing as the use-cases for cloud computing [11] General Dynamics, “High Assurance Platform evolves. Workstation,” Retrieved from Lastly, as mentioned in Section III, the choices of securi- http://www.gdc4s.com/documents/D-HAPWS- ty solutions and approaches for a COE are subject to C&A 60207_p1.pdf on January 6, 2011. requirements before the COE can be deployed and used in [12] C. Hanson, “SELinux and MLS: Putting the Pieces certain environments. This is yet another motivation for lin- Together,” Security Enhanced Linux Symposium, ing up with existing thrusts, reusing components and solu- February 28-March 2, 2006, Baltimore, Maryland. tions being developed with similar goals in mind. We expect [13] Hewlett-Packard, “HP NetTop,” Retrieved from that different deployments will have different C&A require- http://h71028.www7.hp.com/enterprise/cache/48852- ments, e.g., the DoD and IC. Leveraging the C&A that is 0-0-225-121.html on January 6, 2011. part of the development of solutions such as HAP and CDS [14] B. Hicks, S. Rueda, L. St.Clair, T. Jaeger, P. McDa- will shorten the C&A path for a COE. niel, “A Logical Specification and Analysis for SE- REFERENCES Linux MLS Policy,” ACM Transactions on Informa- tion and System Security (TISSEC), Volume 13, Issue [1] Michael Atighetchi, Partha Pal, Andrew Gronosky. 3, July 2010. “Understanding the Vulnerabilities of a SOA [15] R. Meushaw, D. Simard, “NetTop, Commercial Platform - A Case Study,” The 9th IEEE Technology in High Assurance Applications,” Tech International Symposium on Network Computing and Trend Notes, Volume 9, Edition 4, Fall 2000. Applications (IEEE NCA10), 2010, Cambridge, MA. http://www.vmware.com/pdf/TechTrendNotes.pdf. [2] David Bell, Leonard La Padula, “Secure Computer [16] OASIS, Security Assertion Markup Language Systems: Mathematical Foundations,” MITRE (SAML) 2.0, March 2005. http://saml.xml.org/saml- Corporation, March 1, 1973. specifications

[17] OASIS, WS-Security 1.1, http://www.oasis- Recent Advances in Intrusion-Tolerant Systems, open.org/specs/#wssv1.1. March 23, 2007, Lisbon, Portugal. [18] OASIS, WS-SecurityPolicy 1.2, July 1, 2007. [24] Stephen Quinn, David Waltermire, Christopher John- http://docs.oasis-open.org/ws-sx/ws- son, Karen Scarfone, John Banghart, “The Technical securitypolicy/200702/ws-securitypolicy-1.2-spec- Specification for the Security Content Automation os.pdf Protocol (SCAP): SCAP Version 1.1,” NIST Special [19] OASIS, WS-Trust 1.3, March 19, 2007. Publication 800-126, May 2010. http://docs.oasis-open.org/ws-sx/ws-trust/200512/ws- [25] Rick Smith, “Authentication, Crypto, Information trust-1.3-os.pdf Security, and Life with Gadgets,” Cryptosmith, July [20] OASIS, eXtensible Access Control Markup Lan- 7, 2007, www.cryptosmith.com/archives/36. guage (XACML) Version 2.0, February 1, 2005. [26] G. Stoneburner, C. Hayden, A. Feringa, “Engineering http://docs.oasis-open.org/xacml/2.0/access_control- Principles for Information Technology Security (A xacml-2.0-core-spec-os.pdf. Baseline for Achieving Security), Revision A,”. [21] Partha Pal, Michael Atighetchi, Joseph Loyall, National Institute of Standards and Technology, June Charles Payne, Robert Hillman, “Advanced Protected 2004. Services - A Concept Paper on Survivable Service- [27] Sun Microsystems, “DTW – DODIIS Trusted Oriented Systems,” 1st IEEE International Workshop Workstation, Intelligence Paradigm for the 21st Cen- on Object/component/service-oriented Real-time tury,” Retrieved from http://www.sun- Networked Ultra-dependable Systems, May 7, 2010, rays.org/lib/hardware/sunray/ds/go_DTW_cc.pdf on Carmona, Spain. January 6, 2011. [22] Partha Pal, Rick Schantz, and Joseph Loyall, “Mid- [28] Trusted Computer Solutions, “SecureOffice Trusted dleware for Runtime Assessment of Information As- Workstation on Linux,” Retrieved from surance,” The ACM/IFIP/USENIX 11th International http://www.trustedcs.com/products/TrustedWorkstati Middleware Conference (Middleware 2010), Nov 29- onLinux.html on January 6, 2011. December 3, 2010, Bangalore, India. [29] Robert Walker, “Common Operating Environment [23] Partha Pal, Franklin Webber, Richard Schantz, “The (COE) and Global Information Grid (GIG) Enterprise DPASA Survivable JBI- A High-Water Mark in In- Services (GES),” Biometric Consortium Conference, trusion-Tolerant Systems,” EuroSys Workshop on September 22 - 24, 2003, Arlington, VA.