software security requirements for military

SOFTWARE SECURITY REQUIREMENTS FOR MILITARY COMPUTER GENERATED FORCES SYSTEM ARCHITECTURES Sheila B. Banks, Ph.D.

Martin R. Stytz, Ph.D.

Orlando, FL 32828 [email protected]

Wright-Patterson AFB, OH 45431 [email protected]

Keywords: computer generated actors, software security, software architectures, CGF software protection Summary: Military computer generated forces (CGFs) continue to increase in fidelity and breadth of capability, which has resulted in increasing adoption of these systems in military simulation environments in order to increase exercise fidelity. The success and fidelity of CGF software and data are making them increasingly popular targets for software piracy, reverse engineering, and other forms of misuse. The increasing hazard to CGF software can only be expected to increase as the fidelity of the CGF systems and of their data correspondingly increases. Coupled with the ever more tempting target of CGF software and data is the coming increase in computing and networking capabilities that can provide attackers with the tools and computing power needed to mount ever more sophisticated and powerful attacks. Because of the coming cyber threat and the effectiveness with which it can be mounted, current software development practices and CGF architectures must be modified in anticipation of the threat so that CGF software and data are protected. The development and maintenance of CGF software and data must be undertaken with the understanding that the software and data will come under attack in unpredictable ways using unforeseen techniques over the course of their deployment and use. Therefore, the software architecture and its implementation must be written so that it is inherently secure and can exploit continued advances in software and network security technologies. Unfortunately, there are few broad-based technical efforts that are focused on addressing the CGF software and data security need at either the architecture or implementation level. In response to this need, we identified software architecture requirements for CGF software and data security. Until recently, the need for application software protection and security for its data has been addressed indirectly through efforts to provide security for the simulation environment at the network level. The intended targets of the attacks, the software and the data relied solely upon network-based defenses and the operating system for protection. It has become obvious that merely securing the traffic on the network and login access to computers, while necessary, is not sufficient to provide the necessary security for the software and data involved in distributed simulation environments. Indeed, it is apparent that simulation software and data must be protected using a variety of technologies that are embedded in the software and data. These technologies prevent piracy, theft, and reverse engineering of software and data. Additional techniques are algorithms for detection of attempted compromise of software or data, techniques to allow applications to autonomously detect attempts at tampering, and metrics to permit the objective measurement and comparison of software and data protection techniques. All of these CGF security issues come to a point and can be addressed to some degree in the CGF architecture and design. In this paper, we discuss the architectural issues that must be addressed for CGF software and data security. However, current technologies are not sufficient to address the need, so we also present suggestions for future work.

1.

Introduction

The quest to increase fidelity in military simulation systems has fostered increased interest and effort toward development of military computer generated forces (CGFs) that exhibit increased fidelity and breadth of capability. However, there is a down side to the degree of success achieved to date in the CGF arena; the success and fidelity of CGF software and data are making them increasingly popular targets for software piracy, reverse engineering, and other forms of misuse. The security threat to CGF software can only be expected to increase as the fidelity of the CGF systems and their data increases. In addition to increased fidelity making CGF software and data a more tempting

target, the continual increase in computing and networking capabilities provides attackers with ever more powerful tools to allow them to mount increasingly more sophisticated, powerful, and stealthy attacks. Because of the increasing threat to CGF systems and their data, current CGF software development and maintenance practices and CGF architectures should be reconsidered and modified in anticipation of the threat and to increase the protection of CGF software and data. The change in development and maintenance practices for CGF software and data must be undertaken with the understanding that the software and data will always come under attack in unpredictable ways using unforeseen techniques over

the course of their deployment and use. Therefore, new architectures and software must be written so that they are have properties that enhance their inherent security and whose security can be continually improved by exploiting advances in software and network security technologies. In response to this need, we developed software architecture requirements that address CGF software and data security needs. By way of background, until recently the need for application software protection and data security has only been addressed indirectly through efforts to provide security for the simulation environment at the network level. The intended targets of the attacks, the software and the data, had no inherent defenses and relied solely upon network-based and operating system defenses for their protection. Now, though, it has become obvious that merely securing the traffic on the network and login access to computers, while necessary, is not sufficient to provide the degree of security needed by the software and data involved in distributed simulation environments. Rather, it is apparent that simulation software and data must be inherently protected using a variety of technologies that serve to thwart or impede piracy, theft, and reverse engineering. Additional techniques for embedded protection are algorithms for detection of attempted compromise of software or data and techniques to allow applications to autonomously detect attempts at tampering. All of these software protection technologies must be brought to bear to provide CGF security and must be addressed in the CGF architecture and design. To frame the solution to CGF architectural security issues, we developed a set of guiding requirements for security-minded CGF architectures. In this paper we describe security requirements for CGF software architectures that address the needs for CGF security outlined above. In the next section we present a background on related work. Section Three describes the security architectural requirements for CGF architectures. Section Four contains a summary and suggestions for future work.

2.

Background

In this section, we briefly review the types of cyber attacks that a secure CGF architecture must counter, present a strategy for cyber defense, and discuss the protection technologies that can be employed for defense. We then turn to a discussion of the architectural foundations for the architecture. 2.1

Cyber Attacks

To help us in the definition of the secure CGF architecture, we examined the software security literature to determine the types of threats that the architecture must address1-20. The literature review and survey demonstrated that there is no commonly accepted classification of attacks or strategies used to

guide the execution of each attack. As a result, and to help guide our architectural development efforts, we developed our own classification of the types of cyber attacks and the strategies that each uses. To insure that we captured all of the types of attacks and strategies, we used a successive refinement approach to distinguish and classify attacks and strategies. We validated the classification by a re-review of the security threat literature to insure that the attacks and strategies that we identified captured all of the attacks and approaches that have been developed to perform a cyber exploits. As a result of these efforts, we identified three basic attack strategies: 1) to inject faults via the application’s runtime environment, 2) inject faults through the application’s source code, or 3) inject errors to induce a fault. These three strategies can be executed using a variety of techniques and tactics. Additional knowledge related to attacks and their strategies that we found to be useful were limited/circumscribed taxonomies of attack exploits, taxonomies of defensive techniques and technologies, attack vectors and avenues, and improved understanding of how to structure defenses. Additional knowledge that we drew upon includes recent research in vulnerability categories, attack categories, network intrusion detection taxonomies, vulnerabilities that arise from architecture and design choices as well as implementation choices and strategies, development of some metrics and measures for measuring security capabilities, and development of techniques for vulnerability analysis1,4,5,6,9,10,12,13. The literature identifies common errors that enable attacks upon software to succeed. These errors are errors based on allowing an application to make decisions about input based upon the name assigned to the input or the input’s source, failing to restrict what is allowed in the name for an input or the input’s source, and improper or failure to canonicalize a name for an input or the input’s source. One attack vector that does not seem to be considered sufficiently for attacks upon software to succeed is that databases store data that may (or may not) have been checked before it was placed into the database. If the data coming from a database is not checked before it is used by an application, then an attacker can use this attack by changing the contents of the database and creating a malformed response to a query to the database. One form of shared data that does not seem to be considered sufficiently is that databases are shared data and can be a vector for an attack. Common data segments are a potentially fruitful vector for attack and should be protected. There now exist, in book form and on-line, a large and ever increasing library of exploits that can provide insight into attack strategies and tactics as well as insight into hacker methodologies and approaches employed to hijack computer systems, networks, and software applications. Based upon this

material, it is possible to characterize the manner in which an attack proceeds. In general, software application attacks first probe for weaknesses in an application that occur due to poor programming practices or poor design. As a prelude to a follow-on attack, one of the key activities is to examine the software and observe how the software behaves normally and when under stress. Another important prelude is determining code coverage in the application; that is, determining which code paths are exercised when presented with a variety of inputs. For any vulnerability that is found, a follow-up action seeks to exploit the vulnerability with input strings containing executable binaries. This process allows the attacker to either break into the system or hijack the application. One of the most common objectives for an attack is to place a backdoor or rootkit* on the penetrated machine that allows access to and control of the functionality of the targeted machine at the attacker’s convenience. Rootkits can be run locally on the exploited machine or may arrive via another vector, such as a network connection or a DVD. 2.2 CGF Strategy

Architecture

Cyber

Protection

To guide our development of the CGF architecture, we first developed a strategy for architectural cyber defense. To date, no silver bullet solution along traditional lines to the problem of cyber security has been found and none appear to be on the horizon; as a result, we think that a new approach to cyber security should be considered and that researchers and developers should re-examine the application of the idea of defense in depth and determine how it can provide better security for an application than the current layered defense approach. Defense in depth currently operates by using multiple defenses for an application, with the defenses arrayed in such a manner that each defensive layer must be overcome in turn in order to break into a software application. Defense in depth has been a popular strategy for cyber protection. However, it has not been effective and we believe that it is because the paradigm has been improperly applied. The nature of the physical world makes a sequential, layered, traditional defense in depth approach to defense of a physical world object effective because the attacker cannot begin to devise an attack upon a given inner defense until all of the outer defenses are breached. So, in order for an attacker to engage defense at layer n, all defenses at layer zero to n-1 must be defeated in turn However, the cyberworld is different and so reconsideration of *

A rootkit allows an attacker to execute software on a computer at so-called root, or superuser, level of privilege. At the root level of privilege, any operation or action can be performede without restriction. A rootkit can also be used to monitor the kernel from within the kernel in a nearly undetectable manne.

how defense in depth should be applied is warranted. In the cyberworld there is no advantage to be gained by using defenses that are arrayed independently and sequentially because this allows each defense to be defeated independently. For example, the defensive technique at layer n-2 does not support or even hide the defensive technique at layer n-1 because there is no separation in the cyberworld. However, it is known that defense in depth is a good defensive strategy, one that has stood the test of time and proven itself in a variety of circumstances. So, how can the proven defensive strategy of defense in depth be applied in an environment where the concept of physical distance or separation has no meaning? Consider that the basic strategic motivation for defense in depth is that no single defense should be relied upon to protect important items and instead multiple defenses should be employed. As a result, an attacker cannot defeat one defense and thereby gain access to the items being protected. Instead, all defenses must be defeated in turn, and when properly arrayed, the attacker cannot gain insight into one defense while attacking another and, just as importantly, there is a degree of mutual support but not interdependence between defensive layers. Mutual support combined with independence should be the objective for achieving an effective defense in depth in the cyberworld. As regards the cyberworld and the CGF architecture, our problem is to interweave all of the defenses into one layer that would consist of mutually reinforcing but independent cyber defensive measures designed to keep a malicious event from occurring. The interweaving of cyberdefenses forms the heart of our strategy and recommendations for CGF software security.

2.3 Foundational Architectural Technologies To develop a secure CGF architecture, the architecture must exploit the technical advantages offered by object-oriented techniques, component software21-23, software frameworks24,25, gauges, information streams, and containerization26 in order to address a wide variety of CGF requirements27-33. Our rationale for these series of choices is that because of the complexity of the software application that would have to be developed, the architecture should be based to the greatest extent possible upon prior software architectural research efforts. Three key concepts for our work are components, software frameworks, and gauges. A software component is a nontrivial, nearly independent, and replaceable part of a system that fulfills a clear function in a welldefined architecture. In general, a component is an amalgam of objects and encompasses more complexity than is found in a single object. A component is a physical manifestation of an object

(or set of objects) with a well-defined interface and a set of implementations for the interface. Components rely upon a separate infrastructure for interface definitions, message passing, and data transfer. This infrastructure is called a software framework. Frameworks consist of the methods and variables that are used to manage communication between objects and components in an architecture and form a software skeleton for an application that can be customized by a developer. The specification of a framework contains a description of the data and the control flows between the components via the framework, the specification of the interface(s) to the framework, and the documentation of the procedures used to insert a new method or variable into the framework. The framework specification must also describe the functions performed by the framework and all variables used in the framework. One of the chief motivations for and attractions of components and frameworks are their capability for supporting the assembly of systems through composition. A framework should also support experimentation and evolutionary development of functionality for all components and objects in a CGA. Software gauges34 are constructs used to enable rapid assembly of systems. A software gauge is a display system for data collected using a software probe. A software probe collects information by intercepting data in transit between components/objects in a system. Gauges help to insure architectural conformance and help to determine the functional similarity between different components and can be used to verify correct secure behavior by the components of the CGF architecture.

3. Secure CGF Architecture Requirements Traditionally, information assurance and the security of a computation and its data have been provided by the network defensive systems and in the authentication mechanisms in the host operating system 1-20. Despite intense and ongoing efforts to strengthen these two types of defensive systems, they cannot assure the security of software and data on the host computer. These aspects of cyber security must be addressed in any CGF architecture. However, additional security capabilities embedded within the CGF application must also be developed and provided. We will concentrate on CGF system inherent protections in this paper. The protection technologies embedded in the CGF system form the last ring of CGF application software defense. Software defense, also called software protection, is a mix of techniques whose objective is to deny the pirate or intruder the capability to misuse, reverse engineer, tamper with, or steal application software or data. There are two main objectives for practical software protection that must be applied to develop a

secure CGF architecture: 1) To make the task of violating the CGF application so difficult that the effort needed to compromise an application is too great for most attackers and 2) To make the task of breaking into the CGF application so time-consuming that most attackers who could accomplish a penetration cease their attack before they succeed. Furthermore, as a complementary requirement, those attacks that do succeed must be quickly detected in order to limit the damage inflicted. Therefore, a third, subsidiary objective is to permit the application to determine if it has been compromised and to determine where in the application the compromise has occurred. To attain these central objectives, protected software should exhibit five critical properties: 1) It should be difficult to change the overall functionality of the software via small, local changes to the code, 2) It should be difficult to analyze the software’s control and data flows, 3) It should be difficult to determine the software’s runtime behavior, 4) It should be difficult to attack/subvert the software via its execution environment/host platform, and 5) The protection should employ strong cryptographic technologies whenever cryptography is used. Furthermore, defending/protecting software against attacks requires that applications be aware of their environment and must cautiously interact with that environment. Inputs from users, whether those users are human or other software applications, must be carefully scrutinized. Further issues to be addressed for the architecture are the following: 1) Control the use of the system; 2) Prevent extraction of software subsets; 3) Protect the data; 4) Insure correct and accurate execution (unchanged processes that might still produce correct answers or incorrect answers); and 5) Insure that computations are correct and accurate Several other capabilities are needed by the CGF cyber defense. Firstly, the cyber defense should also have the capability to verify that it was invoked by an authorized entity and that the cyber defense still protects its intended target. Secondly, the cyber defenses should be capable of determining if they have been changed. Thirdly the cyber defense should be capable of determining if it is being examined by a debugger, has been placed within a virtual machine, or has been hijacked to another computer system. In addition, recall that our strategy called for the weaving together of the defenses for the CGF application. In order to weave the defenses together, defenses need to be present that operate throughout the application and can be placed within any object or component. Unfortunately, at this time there are few technologies that can be called upon to provide this type of capability. One technology that can be called upon is authentication among components and between components and the overall application. Another capability that can be called upon is digital

signatures. The signatures can be used to allow each component and object to verify that it has not been changed and also allow all called and calling objects to verify that an object has not been changed. Another capability that is needed is secure communication between portions of the CGF architecture, which can be accomplished by applying the concept of virtual private networks (VPN) to the secure CGF architecture. The VPN is supported in the architecture through the use of encryption to create pathways for secure communication between components of the application. Since the framework routes procedure and method calls between the different parts of the CGF software system, the payload for the call can be encrypted using keys known only to the called and calling methods and the framework can be used to examine the call to be sure that it is well formed, conforms to the standards for the CGF, and is going from and to portions of the CGF software that are authorized to communicate. In this manner, the framework for he CGF software application can be used to provide security for the software as well as provide its usual software engineering benefits. Two further needs for CGF cyber security are protection and trust for the contents of the knowledge base and protection and trust of the data that moves into and between portions of the architecture. Trust in the contents of the knowledge base can be addressed through the use of digital signatures to secure atomic portions of the knowledge base. The atomic elements of the knowledge base would have to be identified via analysis during knowledge base design and implementation. However, at whatever level of detail is appropriate the knowledge base contents’ can be digitally signed during knowledge base creation, which would permit the knowledge base contents to be authenticated during execution. As a result we could satisfy our requirement for trust in the knowledge base. As for the issue of protection of data and insuring that it is trustworthy and secure, and payload specification containerization26 combined with the use of the framework to route method calls can be used. Containerization and payload specification would make it very difficult for an attacker to insert or alter data. Frameworks can also be used to secure data by hiding memory locations of called procedures from calling procedures. In this use of frameworks, a calling procedure would only know the name of the procedure it needs; the framework would use the procedure name to determine the address of the desired procedure and the framework would retain the name so that the results of the computation can be returned to the calling procedure. A procedure call would consist of the name of the desired procedure and a container holding the data to be transferred. When the called procedure completes its computations, the resultant data would be placed into

a container and handed over to the framework. The framework would route the container to the calling method. In addition to the objectives discussed above, we have identified the following requirements for a secure CGF architecture. Firstly, a secure CGF architecture must be able to autonomously analyze the results of its cyber defense actions and modify its defensive behavior in response to the results of the analysis. A second requirement is that the secure CGF architecture must be able to be readily programmed with new defensive capabilities that are embedded in the application. Third, to support its own inherent analytic capabilities and those of any human operators, there must be automatic logging of attacks, defensive actions, and responses and there must be a methodology for automatic scoring and assessment of attacks and defensive activity. Fourth, to insure precise and accurate communication between the secure CGF architecture and its operators and between different portions of the architecture, an ontology is needed in order to provide a common terminology and frame of reference. Finally, the secure CGF architecture must be able to respond to multiple simultaneous, independent, coordinated attacks against it within the cyberbattlespace.

4.

Conclusions and Future Work

In this paper, we discussed the CGF software architectural issues that must be addressed when considering CGF software and data security. Because of the growing cyber threat to CGF and simulation systems due both to the value of the data they hold and to the effectiveness with which attacks can be mounted, current software development practices and CGF architectures should be modified in anticipation of the threat so that CGF software and data are better protected. In light of this current and growing threat, CGF architectures must be composed so that they are inherently secure and can exploit advances in software and network security technologies. Unfortunately, to date there are few broad-based technical efforts that are focused on addressing the CGF software and data security need at either the architecture or implementation level. In response to this need, we discussed software architecture requirements that may prove useful in providing CGF software and data security. However, our CGF architecture and software security research has just begun. One issue to be addressed is the development and implementation of the technologies needed to satisfy the requirements that we have identified. To further the CGF security effort, we have identified several research issues. One major need is for research on developing modeling and simulation software protection metrics. Some metrics that must be refined further are resilience (a measure of how difficult is it to defeat a technique), obscurity (a

measure of how difficult it is to determine if a particular protection technique has been employed, aka stealthiness), and expected longevity (a measure of the length of time that a protection technique will afford a worthwhile degree of protection) of each protection technology, the costs and benefits of different mixtures of protection techniques, and the level of protection required for a given application and simulation environment. Additionally, the modeling and simulation community will require means for determining and measuring the required degree of security needed by an application within different types of distributed simulations and scenarios and the technology options available to address these needs. Another need is for the development of test suites to evaluate the protection and architectural conformance to security requirements in a standard, scientific manner coupled with the development of data protection technology assessment standards, standard data sets, and methodologies for evaluating data protection technologies. Clearly, much research remains to be performed before we achieve secure CGF systems, but the growing threat, desire for increased simulation fidelity, and growing use of simulation systems indicate that the research effort should be put forth and that simulation systems and their users will profit greatly from the research investment.

[17] Stallings, W. (1999) Cryptography and Network Security: [18] [19] [20] [21] [22]

[23]

[24]

[25] [26]

[27]

References [1] Erickson, J. (2003) Hacking: The Art of Exploitation. No [2] [3] [4] [5] [6] [7] [8] [9] [10] [11] [12] [13] [14] [15] [16]

Starch Press: San Francisco. Deursen, A. and Burd, E. (2002) 9th Working Conference on Reverse Engineering. IEEE Computer Society: Los Alamitos, CA. Howard, M. and LeBlanc, D. (2003) Writing Secure Code, 2nd Edition, Microsoft Press: Redmond. Huang, A. (2003) Hacking the XBox, No Starch Press: San Francisco. McCkure, S.; Scambray, J.; and Kurtz. (2003) Hacking Exposed: Network Security Secrets and Solutions, 4th Edition. McGraw-Hill: New York. Skoudis, E. (2004) Malware: Fighting Malicious Code. Prentice Hall: Upper Saddle River, NJ. Wang, W. (2003) Steal This Computer Book, No Starch Press: San Francisco. Whittaker, J.A. (2003) How to Break Software. AddisonWesley: Boston. Whittaker, J.A. and Thompson, H.H. (2004) How to Break Software Security. Addison-Wesley: New York. Amoroso, E.G. (1994) Fundamentals of Computer Security Technology. Prentice Hall: Englewood Cliffs, NJ. Denning, D.E. 1999) Information Warfare and Security, Addison-Wesley: Reading, MA. Garfinkel, S. and Spafford, G. (1991) Practical Unix Security. O’Reilly & Associates: Sebastopol, CA. Gollmann, D. (1999) Computer Security. Wiley: Mew York. Jalal, F. and Williams, P. (1999) Digital Certificates: Applied Internet Security. Addison-Wesley: Reading, MA. National Security Council. (1999) Trust in Cyberspace. National Academy Press: Washington, DC. Schneier, B. (1996) Applied Cryptography, John Wiley and Sons: New York.

[28]

[29]

[30]

[31]

[32]

[33]

[34]

Principles and Practice. Prentice Hall: Upper Saddle River, NJ. Summers, R. (1997) Secure Computing: Threats and Safeguards. McGraw Hill: New York. Shrobe, H. (2002) “Computational Vulnerability Analysis for Information Survivability,” AI Magazine, vol. 23, no., 4, Winter, pp. 81-91. Waltz, E. (1998) Information Warfare: Principles and Operations. Artech House: Norwood: MA. Digre, T. (1998) “Business Object Component Architecture,” IEEE Software, vol. 15, no. 5, Sep./Oct., pp. 60-69. Brasse, M.; Huiskamp, W.; and Stroosma, O. (1999) “A Component Architecture for Federate Development,” The Fall Simulation Interoperability Workshop, Orlando, FL, 1217 Sep., pp. 168-174. Cusack, M.A. and Hoare, P. (1999) “Component Based Development in HLA Using Java,” The Spring Simulation Interoperability Workshop, Orlando, FL, 14-19 March, pp. 233-242. Belanger, J-P.; Fortier, P.; and Lam, L. (1998) “Lessons Learned from a Framework Approach to HLA-Compliant Federation Development,” The 1998 Spring Simulation Interoperability Workshop, Orlando, FL., 9-13 March., pp.959-967. Cox, K.F. (1998) “A Framework-Based Approach to HLA Federate Development,” The Fall Simulation Interoperability Workshop, Orlando, FL, 13-18., pp. 1059-1068. Stytz, M. R.; Adams, T.; Garcia, B.; Sheasby, S.M.; and Zurita, B. (1997) “Rapid Prototyping for Distributed Virtual Environments,” IEEE Software, vol. 14, No. 5, SeptemberOctober, pp. 83-92, IEEE Press. Banks, S.B. & Stytz, M.R. (2001) “A Technology Roadmap for Computer Generated Actors,” Proceedings of the 2001 Fall Simulation Interoperability Workshop, Orlando, Florida, 9-14 September, 2001, pp. 725-742. Banks, S.B & Stytz, M.R. (2002) “Technology Review and Future Directions for Computer Generated Actors,” Proceedings of SimTecT 2002: Advancing Simulation Technology and Training, Melbourne, Australia, 13 - 16 May, 2002, pp. 111-118. Stytz, M.R. and Banks, S.B. “Progress And Prospects For The Development Of Computer Generated Actors For Military Simulation Part 3 - The Road Ahead,” Presence: Teleoperators and Virtual Environments, MIT Press, vol. 12, no. 3, December 2003, pp. 629-643. Banks, S.B. and Stytz, M.R. “Progress And Prospects For The Development Of Computer Generated Actors For Military Simulation Part 2 – Reasoning System Architectures And Human Behavior Modeling,” Presence: Teleoperators and Virtual Environments, MIT Press, vol. 12, no. 4, August 2003, pp. 422-436. Stytz, M.R. and Banks, S.B. “Progress And Prospects For The Development Of Computer Generated Actors For Military Simulation Part 1 – Introduction And Background,” Presence: Teleoperators and Virtual Environments, MIT Press, vol. 12, no. 3, June 2003, pp. 311-325. Stytz, M.R. and Banks, S.B. "The Distributed Mission Training Integrated Threat Environment System Architecture and Design," ACM Transactions on Modeling and Computer Simulation, Vol. 11, No. 1, January 2001, pp. 106-133. Stytz, M.R. and Banks, S.B. “An Architecture to Address Uncertain Requirements and Composability for Intelligent Agents in Distributed Simulations,” 3rd International Conference on Hybrid Intelligent Systems, Melbourne, Australia, 14-17 December, 2003, publication on CD-ROM. Stytz, M.R. and Banks, S.B. “Using Gauges and Probes for Distributed Simulation Systems,” Proceedings of SimTecT 2002: Advancing Simulation Technology and Training, Melbourne, Australia, 13 - 16 May, 2002, pp. 125-132.