ADMAS Security Gateway

Transcription

1 ADMAS Security Gateway White paper submitted in response to 2006 Annual ITEA Technology Review June 30, 2006 Submitted by: Aberdeen Test Center and ProObject, Inc Ridge Road, Suite 330 Hanover, MD Phone: FAX: Technical POCs: Tim Kitchens Wayne Parker Al Scramlin

2 Abstract The Test and Evaluation community faces a diverse array of embedded instrumentation challenges with respect to data collection, mobile device security and scalability. This white paper will describe how ProObject engineers and the U.S. Army Aberdeen Test Center (ATC) have applied open source Javabased technologies to address these challenges for the Test & Evaluation (T & E) community as well as the serendipitous benefits of the T&E user experience. 1 Introduction The U.S. Army s Aberdeen Test Center (ATC) tests a wide array of military systems including weapons systems, wheeled vehicles and tracked vehicles. In order to support Sensitive But Unclassified (SBU) data collection from equipment located at various testing facilities/ranges and as part of the Army s Versatile Information System On-line Integrated Nationwide (VISION) initiative, ATC deploys a large family of test instrumentation devices known as Advanced Modular Acquisition Systems (ADMAS). These devices form a networked community of embedded instrumentation (EI) devices and client applications. The EI devices communicate over wireless networks which present a set of unique challenges with regard to security, performance and reliability. The client applications are leveraged by test engineers for command and control and real-time monitoring of test configurations and components. Security is both critical and difficult to achieve in such a highly distributed environment. The ADMAS Security Gateway (ASG) project was undertaken specifically to provide a transparent, non-intrusive security solution. By leveraging leading edge open source 1 technologies such as Java, Java Management extensions (JMX), Java Cryptography Architecture (JCA), AspectJ, and Linux, the ASG project team has developed a highly secure, scalable and easy-to-deploy and maintain solution that addresses security while minimizing the impact to existing testing operations (i.e. during product rollout, etc.). This white paper describes the major ASG requirements and the challenges and constraints faced by the ASG project team, as well as the resulting system architecture of the ASG solution. Following this discussion, we will illustrate how the resulting system provides the serendipitous benefit of a greatly enhanced T & E user experience. 2 Requirements Test engineers leverage a variety of client applications to control and monitor distributed instrumentation devices that are deployed to various ranges throughout ATC. Figure 1 partially illustrates the test system architecture prior to deployment of the ASG system. 1 While some of these technologies do not, strictly speaking, meet all open source criteria (such as the type of license associated with the technology), for the purposes of this paper, we will consider them to be open in that their source code is made available.

3 Figure 1: Legacy System Architecture The below provides a brief description of the major components shown in the diagram: Test client application: Represents one of several types of client applications that interact with ADMAS devices for the purpose of command & control (e.g. change configuration settings) and real-time test monitoring. Test Item: Army equipment, such as, tanks, Humvees, generators etc. that are being tested at ATC test ranges and sites. ADMAS Device: Collects and records data from test items, such as vehicles, generators, etc. Data may include values for temperature, geographic location, voltage, etc. The primary objective of the ASG initiative was to provide enhanced security 2 for these ATC test configurations. The major requirements for the ASG project can be categorized into three distinct areas: 2 1. Security Prevent unauthorized network access to ADMAS device capabilities by: requiring user authentication enforcing role-based authorization disabling direct network routes to devices Provide an extensible user authentication architecture that allows for multiple logon For obvious reasons, we will not provide detailed information regarding the security mechanisms in use past, present or future.

4 mechanisms to co-exist (currently 2 mechanisms are required: logon via central authentication source and logon in a remote environment). The solution should also support the ability to easily add new authentication mechanisms in the future. 2. Legacy Integration Provide a non-intrusive security solution which minimizes the impact to existing operations from a client application, device and end user perspective. One implication of this requirement, for example, is that the ASG solution could not require significant changes to the ADMAS device's existing communications protocols and mechanisms. For example, ADMAS devices send messages to clients over UDP, transfer files via FTP and serve up web pages from an embedded web server. 3. Maintenance and Administration Provide remote deployment, administration and system diagnostic capabilities in a highly distributed ATC environment. In addition, the original (pre-asg) system architecture required that test client application users have a priori knowledge of the network addresses of ADMAS devices with which they wished to communicate. Network addresses represent low-level technical system details. Requiring such detailed technical knowledge presents a disadvantage to users of testing applications. The ASG project also sought to remedy this situation in order to improve the test application user's experience and increase user productivity. 3 The Solution 3.1 ASG Overview System Architecture The ASG architecture is based on the concept of a Proxy or Mediator architecture in which the gateway sits between the clients and devices and provides authenticated and authorized access to the command, control and monitoring operations already available on the ADMAS. Figure 2 below depicts the overall system-level view of the ASG.

5 Figure 2: ASG System Architecture The below provides a brief description of the major components shown in the diagram: Central authentication repository: The ASG supports two distinct authentication mechanisms, one of which is a centralized repository. The central repository is the source of user credentials for this mechanism. Test client application: Same as described in previous section except that clients now communicate with ASG Services instead of directly with ADMAS devices. ASG Client API: This is the object-oriented client-side Application Programming Interface (API) provided by the ASG to simplify and encapsulate all client-asg communications. This API is written in Java and is used by test client applications to communicate with ASG Services over the network. ASG Server: Provides the entry point for all communications between test client applications and ADMAS devices. As previously implied, a server acts as a sort of proxy between clients and one or more devices, ensuring that only properly secured communications occur. This is a Linux-based device and all ADMAS devices connect to it via either Ethernet or Firewire. The Server Device and its physically connected ADMAS Devices form a private network ALL communication to and from ADMAS Devices must go through the Server. The Server connects to the public

6 network via a second network interface. ASG Service: This is the hub from a software perspective of the ASG system. It is a custom Java-based software service that runs on every ASG Server. It provides user authentication and authorization for all ADMAS Devices. In addition to serving as a security gateway, it serves as an ADMAS proxy and provides many performancerelated optimizations that are necessary to compensate for the performance degradation that is a natural consequence of adding a communications layer between client applications and ADMAS Devices. Network Interface Filter: This is a local filter that runs aboard every ASG Server device in order to deny public access, other than via the ASG Service's defined interface, to the ASG and its attached ADMAS devices. Test Item: Same as description in previous section. ADMAS Device: Same as description in previous section. Although there are many other design and implementation details such as the software architecture of the ASG Service itself, the above provides a broad overview of the major system components and their relationships to one another Supported Protocols The ASG Client API interacts with ASG Services (and by proxy with the ADMAS devices attached to them) using multiple communications protocols i.e. TCP, UDP and HTTP. The ASG Client API abstracts away the details of the protocol used for any particular ASG Service interaction from the client application developer since this is considered an implementation detail of the ASG solution. Regardless of the protocol used between any two system components, the same authentication and authorization mechanisms are employed Dynamic Discovery As previously stated, prior to the development of the ASG system, users connected to ADMAS devices by providing the network address (i.e. IP address) of the device with which they wanted to communicate. To overcome this limitation, the ASG architecture introduced the notion of dynamic discovery. This discovery occurs at two major points within the system: 1) Between ADMAS devices and ASG Services: When an ADMAS device starts up, it begins broadcasting presence messages onto the ASG-ADMAS private network. The ASG Service is constantly listening for these messages. 2) Between test client applications and ASG Services: When an ASG Service starts up, it begins multicasting (similar to broadcasting) its own presence messages onto the public network (the one to which client applications are connected). The ASG Client API provides the ability for test client applications to register for notification of availability of ASG Services on the network.

7 This is clearly an advantage for both ASG administrators and client application users. Once an ASG is setup, ADMAS devices can be added in a plug and play fashion no ASG reconfiguration is required. From the user s perspective, interacting with realtime test collection resources is greatly simplified since she no longer must track network addresses. The ASG Client API will locate all ASG Services that control ADMAS devices that conform to the user s profile (via the user s profile attributes) and notify the test client application as services appear/disappear on the network The Role of Open Source Technology in the ASG Solution The ASG solution leveraged several open source technologies such as Java, Java Management extensions (JMX), Java Cryptography Architecture (JCA), AspectJ, and Linux to solve some of the ASG challenges presented. For example, Linux provided a highly customizable operating system that allowed tailoring based on the unique ASG requirements. Similarly, the Webmin tool simplified administrative tasks related to the Linux operating system. Java Management extensions (JMX), which is a Java framework developed primarily for administration and monitoring of remote resources, was selected as the core of the ASG clientserver remote communications infrastructure due to its fit with the ASG requirements and its flexibility. For instance, JMX provides many extension points that developers can take advantage of for customization of the framework. The ASG solution also leveraged an Aspect-Oriented Programming (AOP) framework - AspectJ - to mitigate several cross-cutting 3 issues. For example, this framework was applied to transparently handle network reliability issues such as frequently dropped network connections between distributed system components. Each of the selected technologies above fulfilled a specific purpose in solving the unique challenges presented by the ASG requirements. For each major requirement, an open source technology or tool was investigated and selected for incorporation into the overall architecture based on its capability to solve that specific requirement. 4 Lessons in Open Source Technologies Some of the most generally accepted benefits of open source software have to do with the availability of source code and the lack of licensing fees. If the source code is available, it can of course be modified to suit project needs and more easily be used to troubleshoot any issues that are encountered. If there are no licensing fees, cost is not an issue ( up front costs, in any case). However, as the ASG team came to realize, there is also a tremendous benefit to leveraging open source solutions for systems that have unusual or highly custom 3 The term cross-cutting is used in the AOP community to refer to those requirements that apply at multiple points within the system. Common examples would be logging, auditing and authorization.

8 requirements. There are several reasons for this: Best of breed : For any given software problem, there are likely multiple competing tools/implementations on the open source market. This allows the architect to select the implementation that best fulfills the specific requirement. What you need and only what you need: Due to the nature of open source software, implementations tend to be narrowly focused on a particular problem which results in a reduced footprint you get just the tool you need, no more, no less, in most cases. Commercial implementations cannot typically afford to be so narrowly focused for instance, an Aspect- Oriented Programming implementation would not likely be commercially viable. No one solution can solve the problem(s): When a highly domain-specific solution is required as was the case for ASG, there is no one technology or tool that can do the job. Such a specialized set of requirements necessitates the integration of many technologies. As stated above, there is often no commercially available technology and even if there were, the solution and support for the solution would be extremely expensive. Availability of expertise: Commercial tools tend to have a closed community of specialists. For the most part, there is a fairly narrow set of documentation and expertise available on the market. While this is acceptable when one or possibly two major technologies are in play, this does not work well when several are integrated into a solution. Of all the benefits associated with open source technologies, the most important for the ASG solution was the ability to modify the technology implementation to fit the domain-specific nature of the requirements. 5 Conclusion The ASG project team faced many challenges in addressing the highly domain-specific security requirements posed by the ATC environment. These requirements, along with the constraints imposed by the distributed nature of the testing environment, the many mature legacy systems already in place and the need to minimize the impact to existing operations during and after ASG rollout combined to create a formidable task. This paper illustrates how a flexible system architecture, based on open source technologies, can be designed in order to satisfy the requirements and constraints of such a dynamic environment. It also shows that it is possible to add value for the end user when undertaking projects whose primary goal is to solve an infrastructure issue (i.e. security). Not only does the ASG meet the stated goals of the project, but it also simplifies the test engineer s task in many ways, which will enhance productivity in the long run.