A Framework for Information Security Architecture

26 02 2012

By Hong Zhang

Recently, I have been thinking about how to effectively and efficiently manage the overall information security in a large corporation.  Compounding the complexity of information security, government regulations and compliances with very large amounts of information and data in thousands of information systems located throughout hundreds of geographic locations and used by hundreds of thousands people internally and externally to a large global corporation makes information security management effort overwhelming.  Furthermore to understand the impact of new regulations and/or security standards to the underlying information, data, information systems, locations and people is very time consuming, while quite often the answers are needed in a short timeframe due to security threats.  Having a well-structured information security architecture framework for managing information security in a disciplined manner will be beneficial to information security managers as well as for the entire enterprise.  Since information security is largely tied to almost all information systems across the entire enterprise, information security architecture should be coupled with information systems architecture and also be a part of enterprise architecture.  A comprehensive framework for information systems architecture as well as for enterprise architecture is a natural place to start for defining information security architecture framework.

A Framework for Information Systems Architecture and for Enterprise Architecture

In his article published in IBM Systems Journal in 1987, Mr. John Zachman outlined a framework for information systems architecture.[1]  Later, John Sowa and John Zachman further extended and formalized the framework for information systems architecture in an article published in IBM Systems Journal in 1992.[2]  Since then, Mr. Zachman has applied the same framework to enterprise architecture by changing the target object being described from information systems architecture to enterprise architecture.  Although he has made a few refinements to the graphic representations of the framework to reflect his latest thoughts, the main concept of the framework remains the same.[3][4]

In the past, I had a number of opportunities to have lengthy and detailed discussions with Mr. Zachman relating to enterprise architecture framework and enterprise architecture models.  Through these discussions, I have developed a deep understanding and appreciation of the concept of the framework he created.  I will use the concept of that framework as an example for my discussions here relating to information security architecture framework.  Other enterprise architecture frameworks such as The Open Group Architecture Framework (TOGAF)[5], the EA3 Cube Framework [6], the Federal Enterprise Architecture Framework (EFAF)[7], and the Department of Defense Architecture Framework (DoDAF)[8] can be used as well.

Table 1 below outlines the concept of the framework for information systems architecture and for enterprise architecture created by Mr. Zachman:

 

Data

(What)

Function (How)

Network (Where)

People

(Who)

Time

(When)

Motivation (Why)

Scope

(Planner)

           
Enterprise Model

(Owner)

           
System Model

(Designer)

           
Technology Model

(Builder)

           
Components

(Sub-contractor)

           
Functioning Systems / Enterprise            

Information Security and Information Security Architecture

In U.S. Information Security Law, Section 3542[9], information security is defined as

(1) The term ‘‘information security’’ means protecting information and information systems from unauthorized access, use, disclosure, disruption, modification, or destruction in order to provide—

(A) integrity, which means guarding against improper information modification or destruction, and includes ensuring information nonrepudiation and authenticity;

(B) confidentiality, which means preserving authorized restrictions on access and disclosure, including means for protecting personal privacy and proprietary information; and

(C) availability, which means ensuring timely and reliable access to and use of information.

The term “information security architecture” I used here means a representation of the overall structure for archiving the information security as defined above.

A Framework for Information Security Architecture

The term “information security architecture framework” I used here means a high level structure (a meta-model) for defining information security architecture.

Table 2 below outlines a framework for information security architecture:

 

Data

(What)

Function (How)

Network (Where)

People

(Who)

Time

(When)

Motivation (Why)

Scope

(Planner)

a list of all classes of information that must be protected a list of all classes of relevant activities a list of all classes of relevant locations a list of all classes of relevant people (roles) a list of all classes of relevant events a list of all classes of relevant goals and regulations
Enterprise Model

(Owner)

           
System Model

(Designer)

           
Technology Model

(Builder)

           
Components

(Sub-contractor)

           
Functioning Systems / Enterprise            

Row 1: Scope for Information Security Architecture

A list of all classes of relevant goals and regulations

We first have to understand “why” (in terms of goals and regulations) the information and information systems must be protected.  We may categorize all goals and regulations that the enterprise deals with into a complete list of classes of goals and regulations; then create a list of all goals and regulations that are relevant to information and information systems security.

A list of all classes of information that must be protected

Since information security is about protecting information and information systems, we have to understand “what” the information that must be protected based on the relevant goals and regulations.  We may first categorize all information that the enterprise deals with into a complete list of classes of information; then create a list of all classes of information that must be protected.  Some classes of information might not need to be protected.

A list of all classes of relevant activities

Once we know “what” information must be protected, we have to understand “how” the information is used in terms of activities.  We may categorize all activities that the enterprise involves with into a complete list of classes of activities; then identify all classes of activities that deal with any classes of information that must be protected.  This is a list of all classes of relevant activities.

A list of all classes of relevant locations

Once we know “what” information must be protected and “how” the information is used in terms of activities, we have to understand “where” the information is located and the activities are conducted.  We may categorize all locations that the enterprise deals with into a complete list of classes of locations; then identify all classes of locations that contain any classes of information that must be protected or conduct any classes of relevant activities.  This is a list of all classes of relevant locations.

A list of all classes of relevant people (roles)

Once we know “what” information must be protected and “how” the information is used in terms of activities, we have to understand “who” interacts with the information and/or perform the activities.  We may categorize all people (roles) that the enterprise deals with into a complete list of classes of people (roles); then identify all classes of people (roles) that interact with any classes of information that must be protected or perform any classes of relevant activities.  This is a list of all classes of relevant people (roles).

A list of all classes of relevant events

Once we know “what” information must be protected, “ how” the information is used in terms of activities, “where” the information is located and the activities are conducted, and “who” interacts with the information and/or perform the activities, we have to understand “when” (in terms of events) the information and the activities must be protected.  We may categorize all events (expected and unexpected) that the enterprise deals with into a complete list of classes of events; then identify all classes of events that deal with any classes of information that must be protected, any classes of relevant activities, any classes of relevant locations, or any classes of relevant people (roles).  This is a list of all classes of relevant events.

The above lists of classes of goals and regulations, information, activities, locations, people (roles), and events define the overall scope for information security architecture for a given enterprise.

The first row of the framework (scope) has been completed.  I will continue to discuss additional rows of the framework in the future.

________________

[1] “1987 IBM Systems Journal- A Framework for Information Systems Architecture” by John A. Zachman, http://www.zachman.com/images/ZI_PIcs/ibmsj2603e.pdf

[2] “1992 IBM Systems Journal- Extending and Formalizing the Framework for Information Systems Architecture” by John F. Sowa and John A. Zachman, http://www.zachman.com/images/ZI_PIcs/ibmsj1992.pdf

[3] “Zachman Framework 3.0” by John A. Zachman, 2011, http://www.zachman.com/

[4] “The Zachman Framework™ Evolution” by John P. Zachman, http://www.zachman.com/ea-articles-reference/54-the-zachman-framework-evolution

[5] “TOGAF® Version 9.1 – Enterprise Edition”, http://www.opengroup.org/togaf/

[6] “An Introduction to Enterprise Architecture EA3 – Second Edition” by Scott A. Bernard, 2005

[7] “Federal Enterprise Architecture Framework Version 1.1”, 1999, http://www.cio.gov/documents/fedarch1.pdf

[8] “The DoDAF Architecture Framework Version 2.02”, 2010, http://dodcio.defense.gov/sites/dodaf20/

[9] “U.S. Information Security Law, Section 3542”, http://www.gpo.gov/fdsys/pkg/USCODE-2008-title44/pdf/USCODE-2008-title44-chap35-subchapIII-sec3542.pdf

Advertisements