Requirements, Means, and Architectures all Meet

While understanding information assurance requirements, the means or countermeasures to meet the requirements, and the context or architecture to which they are applied is important, it is equally important to understand how these three things are related. Understanding such a complex set of relationships can be a daunting task. Fortunately, there are a series of models that can help to explain how requirements means and architectures are related .

In 1991, a young Air Force officer, Captain John McCumber proposed what he called a comprehensive model of information security, depicted in Figure 1 (McCumber, 1991).

Figure 1:

What we have been calling information assurance requirements were referred to by McCumber as information characteristics. McCumber referred only to confidentiality, availability, and integrity.

What we call today defense in depth, McCumber called security countermeasures. People, operations, and technology have replaced McCumber s three components of security countermeasures, technology, policy and practice, and training and education in defense in depth.

The third side of McCumber s model was what he called information states. McCumber said that all information exists in one of three states: transmission, processing, or storage. McCumber allows that information can occasionally exist in two of the three states at one time. For example, in a message system, the message could, while in transmission, also be in storage.

In 2001, Maconachy et al. described how INFOSEC has evolved into Information Assurance (IA). This is more than a simple semantic change (Maconachy et al., 2001) ¹ The authors of this new model proposed a number of changes to update McCumber s model. The elements that McCumber called information characteristics were referred to by the authors as security services, and were expanded to include authentication and non- repudiation . The 2001 model also updated McCumber s security countermeasures to the current defense in depth trio of people, operations, and technology. The third side of McCumber s model, information states, was left unchanged. The authors did suggest that a fourth dimension, time, ought also to be considered in several ways. The 2001 model, including a depiction of the time dimension, is depicted in Figure 2.

Figure 2

Today, with the emergence of comprehensive enterprise architecture frameworks, organizations have the opportunity to leverage the holistic approach of enterprise architecture to achieve a more advanced integration of information assurance requirements and countermeasures with the way information is used in an organization than ever before. This opportunity can be conceptually portrayed through a further advancement to the 2001 version of the McCumber model.

While the 2001 version by Maconachy et al. advanced McCumber s three information characteristics to five security states, and updated his security countermeasures to reflect the current defense in depth approach, the transmission, processing, and storage paradigm of information states was left unchanged.

McCumber s intent in describing information states may be viewed as an approach to allow a snapshot analysis of the relationship of information at any point in time within a system to security and countermeasures. His conceptual model has proven to be highly useful for educating information security professionals. At the time it was first conceived, with computer networks and information systems in a state of relative infancy, and true enterprise architecture a distant dream, McCumber s information states were a good enough approach to describing this third dimension of the cube.

Enterprise architecture, as a replacement to McCumber s information states, allows for an unprecedented level of fidelity and understanding of information assurance requirements and countermeasures as they relate to how information is used in the organization. Using enterprise architecture as the third dimension affords an organization the ability to examine information assurance requirements with respect to business processes, operational procedures, and technological infrastructure in an integrated and coordinated fashion. This enhancement of McCumber s model, and the update by Maconachy et al., is depicted in Figure 3.

Figure 3

There are a variety of advantages to be gained by this new approach. Using enterprise architecture provides a mission-technology linkage to which information assurance requirements and countermeasures can be applied. Enterprise architecture also provides a business information-driven approach, as opposed to the earlier models that were systems-oriented.

As all enterprise architectures begin with the mission of the organization, this new model therefore inherently involves top-level leaders , who define the organization s mission.

When the fidelity of enterprise architecture, rather than the earlier information states, is applied to the third dimension of the model, information is portrayed in a much more relevant context.

Enterprise architecture, viewed in relation to information assurance requirements and countermeasures, also creates visibility of role- based perspectives of requirements and defense in depth. Anyone looking at their architectural perspective, whether business process, operations, or technically oriented, should be able to see the corresponding information assurance requirements and countermeasures for that portion of the architecture.

In this way also, senior leaders can be given the opportunity to decide at an enterprise level which information assurance requirements are suitable across the organization. All members of the organization will be afforded the opportunity to participate in defining what necessary information assurance requirements and countermeasures there are for the specific elements of the enterprise architecture with which they are concerned . Everyone in the organization also has their context-appropriate understanding of their role in information assurance.