ISW'98 no.36

[36]

A Domain-Specific, Technology-Oriented Strategy for Information Survivability Analysis

Anh D. Ta
(anhta@mitretek.org)
The Mitretek Systems Corporation
7525 Colshire Drive
McLean, VA 22102, USA
703-610-2529 (voice)
703-610-1603 (voice)

1. PROBLEM CONTEXT

In an age of the global economy and an interconnected world, our "...national infrastructures depend to some extent on underlying computer-communication information infrastructures, such as computing resources, databases, private networks, and the Internet." [1] The importance of this dependency was highlighted by Attorney General Janet Reno in her warning that our national infrastructures have become "...more vulnerable than ever before as we come to rely on technology as never before." [2] In addition, computer-based systems are increasingly being used in business functions that are beyond the traditional back-office operations. For example, shipping companies are providing customers with software applications and access to corporate Internet sites so that the customers can obtain the status of packages being shipped. In fact, implementation of modern business practices (e.g., supply chain management, just-in-time inventory, virtual private network, extranet) requires availability of our national infrastructures.

Today, the management of computer-based systems is complicated by the wide range of technology products each with their individual product life-cycle (i.e., release schedules). Often, the implementation of computer-based systems involves a combination of interdependent technology products, where these products provide functionality ranging from network interfaces to user interfaces. Furthermore, technology products can be used in implementations for different business domains. In addition, an existing implementation must be updated periodically to leverage new technology capabilities as they become available. Otherwise, the implementation becomes unnecessarily constrained by its inevitable dependency on obsolete technologies [3]. In the context just described, it would not be practical to perform an information survivability analysis from a single technology product or a single system perspective.

2. PROPOSED STRATEGY

The position of this paper is to address information survivability by focusing on the common features of technologies being used and how the exploitation of those common features could affect computer-based systems within a business domain. This domain-specific, technology-oriented strategy helps manage the complexity arising from the variety of technology products typically involved in component-based developments. Specifically, this paper describes the potential use of the information collected by Technology-based Domain Analysis (TDA) [4] method to support information survivability analysis.

Technology-based Domain Analysis is a method that focuses on the maintenance and evolution of domain models from the technology perspective. This is accomplished by explicitly capturing technology dependency information as part of the domain model. The technology dependency information is used to determine the scope of the potential ripple effect from substitution either at the technology class level or technology product level. With this kind of information, the domain analyst can maintain domain models by improving the encapsulation for the current technology dependency, or evolve the domain models by preparing a technology migration plan.

Given the fact that TDA only focuses on the technology perspective of domains, it should be used in conjunction with existing functional domain analysis methods, where these methods collect and represent information extracted from the functional perspective of domains. TDA's activities for collecting, representing, and using technology dependency information are integrated into Arango's Common Process for Domain Analysis [5]. The subsequent sections describe TDA's representation of technology dependency information.

2.1 TDA MODELS

TDA focuses on two general technology categories: solution-oriented and development-oriented. The solution-oriented technology is used as a part of the implementation (or solution) and the development-oriented technology is used for generating parts of the implementation (e.g., PowerBuilder GUI tool).

In the TDA approach, information on technology is represented in two contexts: the Domain Model Context and the Technology Model Context. Figure 1 illustrates the TDA modeling contexts that are discussed in detail in the following sections.

Figure 1. TDA Modeling Contexts

2.1.1 TECHNOLOGY MODEL CONTEXT

The Technology Model Context represents the classification and environmental constraints for technologies currently being used in the domain model (i.e., descriptive model) and other available technologies (i.e., prescriptive model). Each technology product currently being used is represented as part of a class structure, using the Unified Modeling Language notation. The class structure convention supports technology classification (i.e., a technology product relationship to a technology class). In addition, the technology class structure conveys information on available technologies by showing related classes or products (or instances). In addition to representing the classification of a technology, the environmental constraints are also captured. An environmental constraint can include dependency on (or the use) of another technology product or the operating system.

To support information survivability analysis, TDA technology models would capture usage issue attribute (e.g., incompatible features) for each technology product. The class structure convention will facilitate the representation of common usage issues for a technology class as well as usage issues unique for each technology product.

2.1.2 DOMAIN MODEL CONTEXT

Using the technology models developed, the Domain Model Context represents information on the technology dependency relationships for domain model content (e.g., product line architecture - the common architecture for a set of systems in a given business domain). Each technology dependency relationship has two attributes. The first attribute is the scope of dependency for domain model content (i.e., the quality of encapsulation of the technology dependency). The second attribute is the degree of specialization of services used (i.e., the uniqueness of the service used as compared to equivalent technology). The explicit representation of technology dependency as a part of domain models provides the "dialogue structure" between the systems engineer, hardware engineer, and software system engineer [6]. Basically, the technology dependency represents the design constraints for software systems in a specific business domain. As an example, Figure 2 illustrates the result of localizing the technology dependencies to individual components (e.g., Ethernet, DECAda, Motif) and system wide (e.g., Ada83).

Figure 2. Localized Technology Dependency

To support information survivability analysis, TDA Domain Model Context would capture hazard attribute (i.e., the set of hazard previously associated with a specific component) for each component of a product line architecture.

2.2 SURVIVABILITY ANALYSIS SCENARIOS

The information represented in TDA modeling contexts can be used in two scenarios: (1) identify potential vulnerabilities (i.e., reactive) and (2) develop "counter" technologies to exploit common features of a specific technology class (i.e., proactive).

Identify Potential Vulnerabilities. In the Technology Model Context, the proposed usage issue attribute for technology models can capture both the issues that are common to a technology class and the issues unique to a technology product. In the Domain Model Context, the scope of dependency information for each technology dependency can help identify components of a product line architecture that potentially could be affected from usage issues. The identified components would be evaluated for its quality of encapsulation for a specific technology dependency. Also, an evaluation would be performed to determine if a usage issue could be resolved by substituting another technology product (i.e., unique usage issues for technology products) or another technology class (i.e., common usage issues for technology classes). This evaluation is based on the assumption that in most cases technology evolves incrementally where new features are based on a standard or emerging design.

Besides identifying vulnerable components in a product line architecture, the technology dependency information can be used as a notification list for usage issues, where the notification list consists of systems that were surveyed to produce the product line architecture. In addition, the environmental constraints captured as part of TDA technology models can be used to identify other technology products that can be affected by a usage issue with a technology class or product (e.g., CERT Advisory CA-98.10 on buffer overflow in MIME-aware Mail and News clients [7] involving various products ).

Develop Counter Technologies. Assuming that the TDA technology models can adequately capture common characteristics for technology classes, the knowledge about these common characteristics can provide a basis to formulate possible methods to exploit the common characteristics (i.e., thinking like a hacker). For example, databases on Unix systems often use input/output ports with addresses above 1024. This common characteristic is not an issue but it can be used in the development of a "counter" technologies to exploit the classes of database on Unix systems.

3. SUMMARY

In summary, the proposed approach provides a framework for the formal collection of usage issues for classes of technology with an emphasis on their use among different domains. Overall, the proposed approach manages the inherent complexity of today's computer-based systems environment by viewing the world at the technology class and product line architecture levels of abstraction. Furthermore, the explicit representation of technology dependency provides the "dialogue structure" for different disciplines or interests within an organization.

4. REFERENCES

[1]: Neumann, Peter G., January 1998, "Protecting the Infrastructure," Communications of the ACM, Vol. 41, No. 1, p. 128.
[2]: Lehman, Ronald F, June 1998, "At the Crossroads of Technology and Policy," Science & Technology Review, Lawrence Livermore National Laboratory, Livermore, CA, pp. 10-16.
[3]: Ta, Anh D., 23-27 September 1996, "Technology Focus As Part of Domain Modeling," Proceeding of NASA Focus on Software Reuse Workshop, pp. 617-620, George Mason University, Fairfax, VA.
[4]: Ta, Anh, Fall 1998, Technology-based Domain Analysis: A Method for Developing Evolvable Domain Models, Dissertation, George Mason University, Fairfax, VA.
[5]: Arango, Guillermo, 1994, "Domain Analysis Methods," Chapter 2, Software Reusability, (Editors) Schafer, Wilhelm, Ruben Prieto-Diaz, and Masao Matsumoto, New York, NY: Ellis Horwood.
[6]: Kumar, Sanjaya, James H. Aylor, Barry W. Johnson, and Wm. A. Wulf, December 1993, "A Framework for Hardware/Software Codesign," IEEE Computer, pp. 39-45.
[7]: CERT, 12 August 1998, Buffer Overflow in MIME-aware Mail and News Clients, CERT Advisory CA-98.10, CERT Coordination Center (www.cert.org), Pittsburgh, PA.

Back to the Table of Contents

[36]