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 se- curity 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