There is no dispute that information survivability "is more than security, more than safety, and more than fault tolerance. It is a combination of quality attributes that assures that even if significant portions of a system are damaged by an attack, accident, or failure, the mission of the network, software, or service will continue." [ISW'98 Call for Participation].

The question that arises is "what kinds of combinations of attributes" are we talking about? Different requirements, needs, and expectations suggest not only that the relative values of the combined attributes vary (e.g., different combinations of "high/medium/low" values of confidentiality, throughput, and availability) but that the attributes in the collection might vary. Thus, a system deemed to be survivable for one mission might be unacceptable for a different mission. If information survivability (IS) techniques are to become standard practice for developers and users, it will be necessary to define ontologies (i.e., definitions, classifications, taxonomies) of the attributes of interest so that various combinations of attributes can be analyzed and evaluated.

A variety of qualitative and quantitative techniques are used for analyzing specific quality attributes [Barbacci et al. 95]. These techniques have evolved in separate communities, each with its own vernacular and point of view and have typically been performed in isolation. However, the attribute-specific analyses are interdependent, for example, performance affects modifiability, availability affects safety, security affects performance, and everything affects cost. In other words, each quality attribute has interfaces to other attributes. These interfaces represent dependencies between attributes and are defined by parameters that are shared among attribute models. If we can identify these interfaces, the results from one analysis can feed into the others. This is the principal difference between an architecture tradeoff analysis and other software analysis techniques-that it explicitly considers the interfaces between multiple attributes, and permits principled reasoning about the tradeoffs that inevitably result from such connections. Other analysis frameworks, if they consider connections at all, do so only in an informal fashion, or at a high level of abstraction.

In [Barbacci et al. 1995] we offered a generic taxonomy for describing various attributes (performance, dependability, security, and safety) and used this taxonomy to describe how each community thinks about its respective attribute:

Concerns - the parameters by which the attributes of a system are judged, specified and measured. Requirements are expressed in terms of concerns.

Attribute-specific factors - properties of the system (such as policies and mechanisms built into the system) and its environment that have an impact on the concerns. Depending on the attribute, the attribute-specific factors are internal or external properties affecting the concerns. Factors might not be independent and might have cause/effect relationships. Factors and their relationships would be included in the system's architecture.

Methods - how we address the concerns: analysis and synthesis processes during the development of the system, and procedures and training for users and operators. Methods can be for analysis and/or synthesis, procedures and/or training, or procedures used at development or execution time.

The safety engineering approach explicitly considers the system context. This is important because software considered on its own might not reveal the potential for mishaps or accidents. For example, a particular software error may cause a mishap or accident only if there is a simultaneous human and/or hardware failure. Alternatively, it may require an environment failure to cause the software fault to manifest itself.

There are also alternative ways to consider the precedence of attributes. For example, "safe software is always secure and reliable" - Neumann [Neumann 86] presents a hierarchy of reliability, safety, and security. Security depends on reliability (an attribute of dependability) and safety depends on security, hence, also reliability.

A secure system might need to be reliable because a failure might compromise the system's security (e.g., assumptions about atomicity of actions might be violated when a component fails).

The safety critical components of a system need to be secure to prevent accidental or intentional alteration of code or data that were analyzed and shown to be safe.

Finally, safety depends on reliability when the system requires the software to be operational to prevent mishaps.

Fault tolerant-techniques can detect security violations - Viruses detected through N-version programming, intrusions detected automatically as latent errors, and denial detected as omission or crash failures.

Fault containment can enhance safety by ensuring that the consequences of a fault do not spread and contaminate other components of a system (thereby limiting cascade effects).

Security techniques can provide fault containment through memory protection, control of communications, and process walls.

The applicability of methods developed for one attribute to another attribute suggests that differences between attributes might be as much a matter of sociology as technology. Nevertheless, there are circumstances for which an attribute-specific mind set might be appropriate. Examples include the following:

The dependability approach is more attractive in circumstances for which there is no safe alternative to normal service-a service must be provided (e.g., air traffic control).

The safety approach is more attractive where there are specific undesired events - an accident must be prevented (e.g., nuclear power plant).

The security approach is more attractive when dealing with faults of commission rather than omission - service must not be denied, information must not be disclosed.

In [Barbacci et al. 1997] we illustrate, through a simple problem, various attribute modeling, analysis, and tradeoff activities. For each of the attribute models we identify those parameters that have a major effect on the results for that model. A sensitive parameter is one that has a great impact on the model. (Variations in the parameter correlate strongly with variations in modeled or measured value.) Parameters that are common to more than one attribute model influence multiple attributes and can be used to trade off between attributes. Sensitive parameters found in only one set may not have been considered by the other model experts, or may not be relevant or sensitive to that model. Sensitive parameters that affect more than one attribute can be positively correlated (i.e., a change in one direction has positive effects on all attributes (win-win)), or negatively correlated (i.e., an improvement in one attribute may result in negative impact on another attribute (win-lose)).

The focus on attribute interfaces forces attribute experts and other stakeholders to communicate through a shared "blackboard." Attribute experts independently create models, then exchange information (e.g., clarifying or creating new requirements), and on the basis of this information, refine the models. The interaction of attribute-specific analyses has a greater effect on system understanding and stakeholder communication than any of these analyses could do on their own. As a result of performing the activities illustrated in this report, the stakeholders have an enhanced understanding of, and confidence in, the system's ability to meet its requirements. They also have a documented rationale for the architectural choices made. This documentation consists of attribute models, the scenarios used in the analyses, and the results of those analyses.

A system developed using the above technique will make the appropriate tradeoffs between the survivability attributes at an early stage - survivability could then be said to have been "designed-in" from the start. Adding survivability late in the design (or worse, to a deployed system) might not be feasible because there may be fewer opportunities for attribute tradeoffs.

References

[Barbacci et al. 1995]

M.R. Barbacci, M.H. Klein, T.A. Longstaff, C.B. Weinstock, "Quality Attributes", Report CMU/SEI-95-TR-021, Software Engineering Institute, CMU, December 1995.

[Barbacci et al. 1996]

M.R. Barbacci, M.H. Klein, C.B. Weinstock: "Principles for Evaluating the Quality Attributes of a Software Architecture", Report CMU/SEI-96-TR-036, Software Engineering Institute, CMU, March 1997.
ftp://ftp.sei.cmu.edu/pub/documents/96.reports/pdf/tr.036.96.pdf

[Barbacci et al. 1997]

M.R. Barbacci, S.J. Carriere, P.H. Feiler, R. Kazman, M.H. Klein, H.F. Lipson, T.A. Longstaff, C.B. Weinstock, "Steps in an Architecture Tradeoff Analysis Method: Quality Attribute Models and Analysis", Report CMU/SEI-97-TR-029, Software Engineering Institute, CMU, May 1998
ftp://ftp.sei.cmu.edu/pub/documents/97.reports/pdf/97tr029.pdf

[Ellison et al. 1997]

R.J. Ellison, D.A. Fisher, R.C. Linger, H.F. Lipson, T. Longstaff, N.R. Mead, "Survivable Network Systems: An Emerging Discipline.", Technical Report CMU/SEI-97-TR- 013, Software Engineering Institute, CMU, November 1997.
http://www.cert.org/research/tr13/97tr013title.html

[IEEE 1061]

"IEEE Standard 1061-1992: A Standard for a Software Quality Metrics Methodology", Institute of Electrical and Electronics Engineers, New York, 1992.

[Neumann 86]

Neumann, P.G., "On Hierarchical Design of Computer Systems for Critical Applications." IEEE Transactions on Software Engineering 12, 9 (September 1986): 905-920.

[Rushby 93]

Rushby, J., "Critical System Properties: Survey and Taxonomy", Technical Report CSL-93-01, Computer Science Laboratory, SRI International, 1993.

Back to the Table of Contents
   [5]