Information Security Today Home

New Books

Critical Infrastructure: Understanding Its Component Parts, Vulnerabilities, Operating Risks, and Interdependencies
Malicious Bots: An Inside Look into the Cyber-Criminal Underground of the Internet, Price $59.95
Information Assurance Architecture, Price $79.95
Building an Effective Information Security Policy Architecture
Information Security Management Handbook, 2008 CD-ROM Edition

Foundational Concepts for Information Assurance Architecture

Keith Willett

Information Assurance Architecture (IA2) is a book on how to think about security in terms directly related to the core reasons for the existence of the organization. In general, the core objective of a commercial organization is to make a profit for investors, the core objective of a government organization is to provide service to citizens, and the core objective of a military organization is to defend national interests. The accomplishment of these core objectives is a complex of constantly evolving strategic and tactical objectives, strategic and tactical planning, projects, acquisitions, implementation, and ongoing operations and maintenance. Each layer, phase, stage, and step must consider organizational risk, including risks to the existence of the organization, risks to fulfilling core objectives, and risks to assets, employees, and infrastructure. IA2 offers a discipline to identify, enumerate, articulate, and address risks at every organizational level in business and technical terms, and to describe those risks in both subjective narrative and objective quantification.

A key objective of this book is to make IA2 practical, useful, and usable as a tool to effectively identify and address organizational risk. The tone of this book will fluctuate in and out of lofty academic discourse and just plain conversational expressions. The lofty discourse is necessary at times to express complex ideas in concise terms, like taxonomies and ontologies. Plain expressions often help make these lofty terms understandable.

Moreover, Information Assurance Architecture provides many frameworks and processes, but also presents a philosophical perspective on IA and IA architecture. This philosophy attempts to get at root principles of why. As an architect, you are very interested in why. Why IA. Why this is a risk. Why addressing this risk is a priority.


This chapter introduces foundational concepts and definitions fundamental to IA2, the IA2 Framework, and the IA2 Process. These concepts include:

  • Enterprise architecture (EA)
  • Systems engineering (SE)
  • Services
  • Mechanisms
  • Information assurance (IA)
  • Information assurance architecture (IA2)
  • IA architectural framework (IA2 F)
  • IA architectural process (IA2 P)
  • Ontology
  • Taxonomy
  • Hierarchy

Why architecture? If one were to say, "I've engaged an architect!" you would likely picture a building construction project. A building architect provides guidance to a builder in the form of blueprints. To produce the blueprints, the architect works closely with the owner or sponsor for the building. The architect discovers the owner's goals and desires. These goals and desires include functional aspects of the building as well as aesthetic aspects. Moreover, the architect considers the environment in which the building will reside, including the climate, sunrise, and sunset, all with the intent to create a useful, efficient, aesthetically pleasing structure. The architect creates elevations, models, and finally blueprints that describe the relationship among the building site and the building's floors, walls, light, and space, all of which have been designed to meet the owner's requirements.

What if the construction project were to build a business, a nationwide enterprise, or a global enterprise? Initial thoughts would be to engage accountants, lawyers, and business professionals in marketing, supply line management, and other such expertise. Although this is good, how do these people know that they are doing the right things in the context of a larger plan? Is there such a thing as a business architect? Yes, and they are referred to as enterprise architects; enterprise architects develop enterprise architectures. So, now there is this enterprise architecture that describes the complexities of the business, assets, people, technology, relationships, and operations. How do you safeguard these assets? How do you ensure continuity of operations? Maintain organizational viability? The answer resides in the services of an architect for security.

What will a security architect design? If organizational wealth is physical assets like currency or gold, a prudent security architecture includes safes, vaults, door locks, and surveillance equipment. In the contemporary business environment, most organizational wealth is now largely bits* on a hard drive. The transfer of organizational wealth (e.g., employee payroll via direct deposit and interorganization transactions) is bits traveling across a wire. Physical buildings and land no longer represent the largest portion of organizational value; instead, most organizational assets are intellectual property in the form of either employee knowledge or documents and information-most of these are in the form of bits on electronic media (e.g., a hard drive).

The mission of the information assurance architect is to develop an information assurance architecture and align IA with the enterprise architecture (EA) to ensure appropriate safeguards that maintain the organization's operational integrity and long-term viability.

An effective IA2 practitioner must have a breadth and depth of experience with technology, security, and business. The intent of this book is to provide the IA2 practitioner with a disciplined thought process for IA planning and integration of IA in the enterprise.

Foundations of Successful Architecture

Foundations of any successful architecture, be it enterprise or information assurance, include:

  • Lexicon
  • Standards
  • Means
  • Method
  • Motivation
  • Mission

A lexicon is a dictionary of the words and phrases pertaining to a particular subject. A lexicon ensures that all stakeholders with an interest in a project interpret and use the same language consistently. For example, risk means different things to different people and may mean different things to the same person in different situations. The debate on whether a definition is right or wrong can go on ad infinitum. The important point is for everyone to agree that for now the working definition is as the lexicon states.

Standards provide a baseline upon which to build a successful IA architecture. Using an industry standard means that the approach, the details, or both can be vetted against an accepted reality. Rarely will any one standard address all organizational needs. However, using standards within an architecture removes the perception of arbitrariness and provides a credible reference point from which to customize the organization-specific solution.

Means are the available resources and include people, expertise, time, material, and budget.

Method is a prescribed manner to proceed. The IA2 Framework and IA2 Process together provide the IA architectural method.

Motivation is a set of reasons. The root motivation for IA architecture is to recognize the presence of business risk and address it appropriately.

Mission is a specific focus. The specific focus for IA2 may be a system, a business function, a technical service, a group of people, or the overall IA posture of the enterprise.

Architecture Terminology
Architecture is the art of consciously forming a coherent structure. In a technical environment, an architecture view is a "representation of a system from the perspective of related concerns or issues," "a collection of logically related models." An architectural framework is "a standard for the description of architectures." Architecture addresses not only structure, but also behavior of systems and data, as well as behavior of people in terms of relationships, actions, and cognition.

An architecture is a unifying structure using a set of design artifacts and descriptive representations to describe an entity such that it can be produced to requirements and be maintained over its life cycle. An entity may be physical, logical, system, cyber, or a combination of these. An architectural process provides a disciplined methodology to promote repeatability, consistency, high quality, and complexity management.

Enterprise Architecture and Systems Architecture
Architecture is a multidimensional practice. Challenges facing the architect include paradox, dichotomies, balancing a multitude of tasks, deadlines, conflicting premises, constraints, uncertainty with existing information, and missing information. Critical architectural decisions may include many assumptions (a professional euphemism for guesses). A structured approach to architecture provides a method to minimize assumption uncertainty. An effective architectural approach addresses enterprise architecture (the big picture) as well as systems architecture (the pieces comprising the big picture).

The Global Enterprise Architecture Organization (GEAO) describes enterprise architecture as follows:

The way in which an enterprise vision is expressed in the structure and dynamics of an Enterprise. It provides, on various architecture abstraction levels, a coherent set of models, principles, guidelines, and policies, to translate, align, and evolve the systems that exist within the scope and context of an Enterprise.

An EA process is a methodology that aligns solutions (business, technical, operations, etc.) with organizational core mission and strategic direction in terms of to-be, target architecture; as-is, current architecture; and transition, migration plan from as-is to to-be.

Understanding that systems comprise the greater enterprise, there is a distinction between enterprise architecture and systems architecture. A system may or may not be a computer system, but is by definition an entity that accepts input, performs a process, generates output, and reacts to feedback; e.g., nervous system, economic system, or computer system. Based on the GEAO definition of enterprise architecture, system architecture is defined as follows:

Systems architecture refers to the way in which a system vision is expressed in the structure and dynamics of the system and often in context of a collection of systems. It provides, on various architecture abstraction levels, a coherent set of models, principles, guidelines, and policies, used for the translation, alignment, and evolution of the components that exist within the scope and context of a system.

Enterprise architecture and system architecture are complex practices of abstraction that provide guidelines to develop business solutions without regard to specific services or mechanisms. Information assurance architecture is itself a complex practice of abstraction requiring a melding of architectural concepts, information assurance concepts, and the development of new terms to describe nuances of the IA2 practice.

Most people in technology think in terms of the technology they are familiar with and the operations that technology supports. Although this is not bad, it is not enough. The architect needs to think in abstract terms of hierarchies, taxonomies, and principles that emphasize the business perspective and guide the mechanisms that support operations. A business driver of secure communications between the Internet and the internal network results in IA services and IA mechanisms to support that business driver. The size, complexity, type, and notoriety of the organization drive the breadth and depth of these IA services and mechanisms. A small Midwest insurance agency is unlikely to be a direct target of international cyber terrorism; however, it may be an indirect victim of a cyber virus in the wild.

A prudent precaution is for this small Midwest company to install anti-malware on servers and desktops to protect itself from incidental infection. A government organization of military and political significance is more likely to be under direct attack from not only conventional malware, but also unique malware specifically targeted at that organization. This government organization requires a significantly larger investment in defense, monitoring, and response with respect to malware.

The architectural process assists in discerning these differences and providing the appropriate safeguards to balance operational effectiveness, security, and cost.

Information Assurance: A Working Definition
An abstract organizational mission statement reads: Provide the people we serve with quality products and services on time, within budget, and within specified service level agreements (SLA). The ultimate focus is on stakeholder value. Stakeholder value may be shareholder value in the private sector or constituent value in the public sector. Whatever the mission, it requires operational integrity-operations must continue despite incidents that may interrupt, information must be accurate despite incidents that may corrupt, and information critical to mission success must be kept confidential from competitors, enemies, or other opposition despite incidents that may disclose. Many factors, including buildings, utility services (i.e., power and water), personnel, and information technologies, support the mission. Information assurance defines and applies a collection of policies, standards, methodologies, services, and mechanisms to maintain mission integrity with respect to people, process, technology, information, and supporting infrastructure.

Information assurance addresses information, not just information technology. A chief information officer (CIO) is responsible for information, not just information technology. Information assurance provides for confidentiality, integrity, availability, possession, utility, authenticity, nonrepudiation, authorized use, and privacy of information in all forms and during all exchanges.

Mission Integrity versus Mission Entropy
To maintain mission integrity, all relevant operations are working toward the fulfillment of the mission within an acceptable level of deviation. When operational levels exceed deviation parameters, operations have entered a state of mission entropy. Deviation parameters define a fuzzy line separating mission integrity (successful mission fulfillment) from mission entropy where mission success is in jeopardy (Figure 1).

Figure 1 Mission integrity boundary model.

The goal of IA is to keep operations within acceptable deviation from that ever-elusive goal of perfection; that is, IA attempts to keep operations within acceptable mission integrity boundaries. When mission entropy threatens, corrective action is required to move operations back in line. It is possible to introduce too much security and introduce mission entropy (e.g., shutting down external Internet access is very secure but unacceptable when the E-commerce site generates 80 percent of revenues). IA must balance the right amount of security with the right amount of freedom to operate.

The need for corrective action to maintain mission integrity emphasizes the importance of knowing how to anticipate, defend, monitor, detect, alert, respond, and correct such deviations. Information Assurance Architecture presents many frameworks, processes, services, and mechanisms to ensure corrective action. Note the purpose of IA2 is not to teach these security services and mechanisms; there are many excellent references on security operations, firewalls, intrusion detection systems (IDS), disaster recovery planning, etc. Rather, IA2 presents various ways to think about security services and mechanisms, and how to apply them to design and implement IA to achieve optimum effectiveness in context of business drivers and business risk.

Melding Architecture and Information Assurance
Using the definitions for architecture and information assurance, Table 1 presents IA architectural terms critical to understanding IA architectural concepts.

Table 1 Information Assurance and Derivative Terminology
IA Term Definition
Information assurance (IA) Defines and applies a collection of policies, standards, methodologies, services, and mechanisms to maintain mission integrity with respect to people, process, technology, information, and supporting infrastructure.
Information assurance architecture (IA2) The art of consciously forming a coherent structure of information assurance services and mechanisms
IA2 Framework The basic conceptual structure for defining and describing an IA2 solution
IA2 Process The steps required to generate an information assurance architecture

The discipline of architecture uses terms of particular nuance. This book attempts to use these terms in a manner widely accepted; however, given the nature of the topic, this book introduces new terms surrounding IA architecture. The glossary provides a lexicon to distinguish the nuances among these terms. Understanding these terms is essential to understanding the IA architectural concepts herein. This book is internally consistent in the use of the terms as defined in the glossary.

Systems Engineering
A system is a collection of entities (real or virtual) that interact to produce an objective or result. Systems engineering (SE) is a discipline to plan for and ultimately produce a system. Systems engineering may follow the guidance provided by an enterprise architecture to implement the intent of that architecture. This may include the information assurance services and mechanisms in the appropriate context of managing business risk. IA2 is a discipline for IA that also applies to the requirements engineering aspect of SE.

The traditional use of SE is to produce a system of known and definable operation. The environment within which the system will work is known, inputs are well defined, and the interactions of the system are known (the providers of inputs and the consumers of outputs). There is an emerging need to provide an engineering discipline to systems or solutions that must operate today, but may operate in an environment where the expectations of that solution are not predictable. For example, a Web service may be used in manners completely unexpected by the developer.

There becomes a need to define the environment very well and prescribe the rules necessary to operate in that environment. That environment may be a technical environment or it may be the enterprise. The enterprise environment looks at combining services in as many ways as it takes to produce results effectively. Therefore, there is an emerging need for a discipline of enterprise systems engineering.

Ontologies, Taxonomies, and Hierarchies

An ontology is an orderly classification; an ontological class represents an abstract ideal. An instance is a specific example of something within that class; IA2 is an instance of an ontology for addressing information assurance from an enterprise architecture perspective. A taxonomy is an orderly classification to define relationships between classes; IA2 uses taxonomies in process flow descriptions to establish relationships between classes. A hierarchy is a top-down structure that denotes superior-subordinate relationships. A hierarchy may represent a control structure, a classification structure, or an organizational structure.

Context and Perspective

This book uses the terms context and perspective a lot. Context is the environment within which something exists or resides. An enterprise context is the entire organizational environment; an organizational structure context is the environment of the hierarchical relationships within the enterprise. Perspective is a point of view. For example, an executive (CEO) perspective on a project looks for the benefit to stakeholders in terms of return on investment; the system administrator perspective looks for the benefit to users in terms of providing the capabilities and performance they expect. The appropriate application of architecture is context dependent. Moreover, the architect must see things from the perspective of many different people and must look at things from a business perspective and technical perspective.

Identify, Enumerate, Articulate, and Address

The main theme in this book is IA2 as a discipline to identify, enumerate, articulate, and address risks. To identify risk is to discern the characteristics of the risk, those distinguishing features that provide identity to that risk. To enumerate risks is to list all the relevant risks. To articulate risks is to elaborate on the characteristics, to give them business meaning, an enterprise context, and make them understandable. To address a risk is to acknowledge its existence and state how to deal with it in terms of accept, ignore, transfer, share, or mitigate.

An important distinction is that to address risk is not necessarily to spend money to mitigate that risk. A perfectly legitimate manner of addressing risk is to state that the organization chooses to accept that risk and provide a rationale as to why.

Summary and Conclusion

The IA architect needs a framework, a process, and a set of tools, templates, and methods to produce an IA architecture. These IA2 constructs provide the ability to address IA comprehensively in terms of business risk as well as in technical terms meaningful to developers, implementers, and operations. These IA2 support artifacts also provide a repeatable, consistent methodology for producing IA architectures. Caveat: No matter the supporting frameworks, tools, templates, etc., architecture can never be a cookie-cutter, rote process performed by anyone who reads the manual and follows a checklist. Architecture is an art that uses the discipline of science to help guide the architect through the methodology.

The fundamental concepts in this chapter provide a basis for understanding the IA2 Framework and IA2 Process. The next chapter uses these concepts to define an IA2 Framework.

About the Author
From Information Assurance Architecture by Keith D. Willett. New York: Auerbach Publications, 2008.

Subscribe to
Information Security Today

Powered by VerticalResponse

© Copyright 2008 Auerbach Publications