Enterprise Architectureand Security IntegrationBy Tim Braithwaite
Included in this preview:
• Copyright Page
• Table of Contents
• Excerpt of Chapter 1
For additional information on adopting this book for your class, please contact us at 800.200.3908 x71 or via e-mail at [email protected]
Sneak Preview
ENTERPRISE ARCHITECTURE
AND
SECURITY INTEGRATION
…
Third Edition
By
Timothy Braithwaite
Copyright © 2011 University Readers Inc. All rights reserved. No part of this publication may be
reprinted, reproduced, transmitted, or utilized in any form or by any electronic, mechanical, or other
means, now known or hereafter invented, including photocopying, microfi lming, and recording, or
in any information retrieval system without the written permission of University Readers, Inc.
First published in the United States of America in 2010 by University Readers, Inc.
Trademark Notice: Product or corporate names may be trademarks or registered trademarks, and are
used only for identifi cation and explanation without intent to infringe.
15 14 13 12 11 1 2 3 4 5
Printed in the United States of America
ISBN: 978-1-60927-966-0
CONTENTS
PART ONE
Introduction 3
Chapter One: Statement Of The Problem 7
Chapter Two: The Baseline From Which To Address 19
Governance, Security and CIP Issues
PART TWO
Chapter One: A Security Knowledge Framework For 29
Managing Enterprise-Wide Information Systems
Chapter Two: Using The Security Knowledge Framework 39
APPENDIX A 71
APPENDIX B 95
BIBLIOGRAPHY 121
INDEX 123
BIOGRAPHY 127
PART ONE
Introduction 3
This book explores the increasingly important task of integrating Information Security and
Assurance (IS/A) policies, technologies, and practices with the documented work products of
an organization’s Enterprise Architecture (EA).
In a practical vein, this book examines the information technology (IT) management implications
of three contemporary challenges confronting the Boards of Directors of U.S. and European corpora-
tions and offi cials of government agencies; and off ers a strategy for their solution within the context of
enterprise architecture and information security/assurance integration.
Th e three challenges:
#1 – the renewed emphasis on integrity and accountability in the governance of corporate and
government organizations,
#2 – increasing concern for the vulnerability of technology dependent organizations to information
processing and electronic business (e-business) security threats, and
#3 – post 9/11 demands to provide corporate and national Critical Infrastructure Protection (CIP)
against terrorist attack and natural disaster.
Th e book will focus on how the time and money spent in creating and maintaining the EA can also
yield, with little additional eff ort, an integrated Enterprise Security Architecture (ESA) that addresses
the three challenges and a host of other IT management and security related issues. Th is approach will
deliver the following benefi ts to the enterprise: solutions that result in a security architecture that is
consistent with the EA and aligned with the operational uses of technology across the enterprise.
• Addressing each of the three challenges will serve to illustrate the complex and essential nature of today’s need
for IS/A and demonstrate how the IS/A requirements for integrity, confi dentiality, and availability (ICA) go to
the very heart of how e-business systems are defi ned, designed, implemented, operated and maintained.
• Since most of the information needed to analyze and design an ESA is already available within an EA, much
of the duplication of eff ort currently expended by diff erent organizational groups (i.e. the EA team and the
security staff ) can be avoided.
• Collaboration by EA and security analysts will result in an enhanced understanding of the systems comprising
the enterprise which, in turn will improve the integration of solutions to the IS/A challenge – solutions that
result in a security architecture that is consistent with the EA and aligned with the operational uses of technol-
ogy across the enterprise.
• By demonstrating that the ESA is necessary for the comprehensiveness of the EA traditional IS/A funding
obstacles are lessened because costs will now be directly linked to the same Return on Investment (ROI)
calculations used to justify the business system being protected.
Introduction
4 Enterprise Architecture and Security Integration
• Considering human nature, the creation of an EA and its subordinate ESA will experience the waxing and
waning of executive support. By joining forces, each community of interest – EA and security – can work
together to keep management focused on the importance of executive involvement and the necessity for
adequate funding to both create and maintain each architecture.
FEATURES OF THIS BOOK
Th is book was written for the expressed purpose of bringing together the business and technical profes-
sionals needed to develop meaningful and secure enterprise architectures. It has several unique features.
1. It does not spend a great deal of time trying to convince the reader there are information security/assur-
ance problems associated with the use of computer technology. Appendix A provides a short treatment
of the IS/A problem focusing on the e-business requirements of integrity, confi dentiality, and availability.
Th e book assumes that the reader is already informed about security and assurance issues, has access to
security experts, and is concerned about securing the information processing capabilities of the enterprise.
2. Th e book identifi es the essential knowledge needed to identify the ICA requirements of business for
inclusion in the enterprise architecture. It acknowledges that security architecture implementations of
controls and procedures to meet specifi c ICA requirements will be determined within the context of each
unique line of business and the discipline of risk management.
3. It presents a pragmatic view of two complex topics – Enterprise Architecture and Information Security
and Assurance – topics that have come to be dominated by vendor hype and self-serving promotions that
are not always in the best interest of the enterprise.
4. It is about “process” – the establishment of EA and IS/A management processes that will outlive the
“architectural and security crisis of the moment” and create an institutionalized format for the “continu-
ous” future improvement of both aspects of the enterprise.
5. It proff ers that technology systems, as well as the EA and ESA models of the enterprise, will never be
accurate or secure unless and until business information itself is seen to be an asset of critical importance
that demands to be managed as rigorously as any other asset of the enterprise.
TARGET AUDIENCE FOR THIS BOOK
Th is book is indispensable for those responsible for:
• Executive oversight of the EA and those senior managers who will participate in the formulation of enterprise
goals, objectives, performance measures, security metrics, and business models.
• Developing secure enterprise architectures for their business or government agency.
• Participating in the EA initiative of their organization for the purpose of securing systems currently under
development.
• Improving existing analytic tools with a specialized area of knowledge (i.e. security integration) required for
developing successful enterprise architectures.
• Implementing Sarbanes/Oxley, the OECD Principles of Corporate Governance and other international guid-
ance on corporate governance, and U.S. Federal and State IT and Security management laws and regulations
such as the Federal Information Security Management Act (FISMA).
Introduction 5
• Developing comprehensive investment strategies to include Return on Investment (ROI) and Return on
Security Investment (ROSI) and Capital Planning and Investment Control (CPIC) plans.
PREREQUISITES
Working experience and knowledge of at least two of the following:
• Business systems analysis and design techniques to include use of system modeling tools,
• Requirements analysis,
• Security/information assurance analysis and design,
• Risk Analysis,
• Quality Assurance,
• Validation, Verifi cation, and Testing,
• Security Certifi cation & Accreditation (C&A),
• An understanding of EA concepts – review Appendix B.
HOW THE BOOK PROCEEDS
In order to provide practical assistance, the book presents an essential EA analytic and knowledge
management tool, the Security Knowledge Framework (SKF). Th e SKF is to be used in achieving
conformance with prevailing information security/assurance, critical information infrastructure pro-
tection, and governmental and corporate governance demands. Th e SKF, covered in Part II of this
book, is compatible with the seminal work of John Zachman. His Information Systems Architecture
Framework, developed in 1987 and enhanced in 1992, provides a logical construct for defi ning the
components of an information system, their interfaces, and interactions.
As a Zachman-compatible framework, the SKF provides tailored “prompts” and “cues” asking for
information which, when assembled, assures the development of an EA that demonstrates that integrity, confi dentiality and availability requirements are understood and that solutions to those requirements
exist (or will exist) in the systems that comprise the enterprise. Use of the SKF assures the development
of an ESA that is aligned and consistent with the EA of the business or government agency.
Th e strategy for carrying out this integrated analysis is to bring a security focus to the methodolo-
gies, diagnostic processes, and tools already being employed in the creation, use, and management of
an EA. Th is is accomplished by conducting the characteristic EA analysis but complemented by the
SKF to assure inclusion of information security and assurance issues.
It is not a goal of this book to create additional work for anyone. Th at would be counter-productive
in work environments already overstressed by endless studies, analyzes, and reports to headquarters,
congress, and various oversight groups. Th e goal is to direct attention to those elements of knowledge and
system “artifacts” that are required to formulate a sound ESA.Put simply, an EA, with its’ ESA extension, is a way to conceptualize, model, and document all ele-
ments of a business system and its’ policy, procedural, organizational, informational, and technological
manifestations. It is the preferred way to manage the complexity of contemporary computer-dependent
organizations. An EA, augmented by an SKF assessment, models and documents the enterprise, includ-
ing its’ information security/assurance requirements, and conveys that knowledge to system designers,
6 Enterprise Architecture and Security Integration
implementers, and operators so as to protect the enterprise against threats to integrity, confi dentiality,
and availability.
Using the SKF approach, every business activity likely to be infl uenced by the three challenges
will be subdivided into their constituent parts (i.e. system and nonsystem), analyzed for their ICA
requirements and redesigned and/or modifi ed to answer those needs in a manner that is prudent and
compatible with the overall EA.
BACKGROUND DISCUSSION
Th e analytic discipline known as EA has come of age during the last decade and shows great promise
at this critical point in the evolutionary path of bringing information technology to bear on enterprise
business functions (See Appendix B).
At a time when organizations want to capitalize on the interactive advantages of the Internet, the
creation of an EA captures and creates the comprehensive knowledge necessary to facilitate new (“to
be”) designs while providing the documentation needed for effi cient and eff ective (“as is”) systems
management. At the same time, EA provides answers to many of the problems that have historically
plagued business and government concerning the use of information technology (IT).
A review of the perennial concerns listed by CEOs, COOs, CIOs, and other senior general manag-
ers serves to illustrate the types of information technology problems that a conscientiously developed
and maintained EA could be instrumental in addressing.
Problem How EA Helps
Value for IT Investment IT Decisions are based on Business Need and Return
on Investment (ROI) Analysis
Business/IT Alignment IT uses are derived from Business Plans and Business
Rules
Customer Service Focus IT and Manual Processes are designed to be mutually
supportive
IT Strategic Plan A Fundamental Result of EA eff ort
IT input to Business Plan A Fundamental Action of EA eff ort
Audit of System Management Provides information and insight into neglected areas
of operational practice
Organizational alignment of IT Proper alignment achieved since IT Systems &
Resources now support business processes
Obtaining Suffi cient Resources IT Resources are justifi ed by Business ROI
Support for IT Investments EA clearly identifi es IT/business dependencies,
priorities and ROI
Successful IT Systems Better understood dependencies help to insure better
design of systems
Adequate & Skilled Staff Better understood dependencies help to assure proper
staffi ng & training
Information Security/Assurance Improves insight into the problem, generates clearer
statement of requirements and risk metrics, design of
integrated solution sets, and aids in the development of
dual business/security ROI Statements.
Statement Of The Problem 7
NOTE – Depending on the reader’s depth of knowledge and understanding attention is directed to following
supplemental reading:
Appendix A: Information Security/Assurance (IS/A) – A PrimerAppendix B: Enterprise Architecture (EA) – A PrimerEach appendix is specially written to support the materials that follow.
DEFINITIONS AND CONCEPTS
Information Security/Assurance (See Appendix A)
Before a discussion of the working concepts presented in this book, it is necessary to recount
the evolution of security terminology and show how confusion can exist when such terms
as information security and information assurance are used interchangeably. Th is is important
because much that is written and many of the laws and guidance documents in use have not been
reconciled with the latest consensus defi nitions.
In earlier times, eff orts to address the evident lack of controls over automated systems were variously
known as computer security (COMPUSEC), communications security (COMSEC), emanations
security (EMSEC), information security (INFOSEC), and information technology security (ITSEC).
More recently, cyber-security and information assurance (IA) have come into vogue. In each instance,
new terminology was created to describe areas of concern where vulnerabilities (i.e. exploitable weak-
nesses) in computer and communication systems had been discovered. Th e latest and most accurate
terms information assurance, combines the broad grouping of earlier concerns with the additional
issues of how “systems” are defi ned, designed, tested, and operated in order to assure integrity, confi -
dentiality, and availability of computing resources. For the remainder of this book and to facilitate clear
communications, the combined expression of Information Security/Assurance (IS/A) will be used.
For our purpose, Information Security/Assurance (IS/A) is concerned with all aspects of how busi-
ness and government information is collected and handled, how hardware and software process and
communicate that information, how information is stored and protected from eavesdroppers, and how
system resources are confi gured, protected, and backed-up to ensure their integrity, confi dentiality, and
availability to legitimate users and customers/citizens. Within the context of enterprise architecture the
IS/A defi nition extends to manual information handling and processing as well.
Chapter One: Statement Of The Problem
8 Enterprise Architecture and Security Integration
“Trusted for Use” (See Appendix A)
Terminology is confusing and, at times, used interchangeably. Th e phrase “trusted for use” is my
attempt to describe the desired condition under which a system is expected to operate. Th e phrase can
also be used to describe the condition of inputs to a system and outputs from a system as well as the
state and condition of software and equipment used to run a system. It follows then that “trusted for
use” could also be used to describe the state and condition of products from the developmental stages of
systems design and implementation as well as the state and condition of hardware or software acquired
commercially.
In the context of IT, the phrase “trusted for use” describes the desired state and condition of all infor-
mation technology in service to the enterprise. Aside from the realm of simulation and modeling, the
purpose of information technology is to faithfully present reality in a digital form – a digital form that
can be used, with confi dence, for decision-making. Th is is the business of IT! Th is is the value of IT!
Ease of access, speed, storage capacity, presentation technologies, portability, expandability, com-
patibility, usability, low cost, all mean nothing if the ability to faithfully represent reality is lost. Th e
universe of threats (i.e. ways in which the ability to represent reality can be lost) are categorized and
summarized under the banner of Information Security/Assurance in the following way.
First, are threats to the integrity of data/information, software, and the computers and network
involved in processing and communicating that can prevent their being “trusted for use”.
Second, are threats to the confi dentiality of corporate information, processes, and customer/citizen
data. Breaches of confi dentiality result in violations of the “trusted for use” specifi cation used in systems
design.
Th ird, are threats to automated information and computer processing systems preventing their
availability when they are needed to conduct the authorized business of the enterprise. Such threats
constitute a violation of the “trusted for use” criteria whenever a system is prevented from operating
according to a system’s availability and reliability demands. Th is can be especially serious for organiza-
tions that conduct on-line, 24x7 operations where “the business is the system”.
Note that some documents treat authentication and non-repudiation as defi nitional sub-elements
of information security/assurance. In others, they are viewed as techniques to be employed to insure
integrity, confi dentiality, and availability. For our purposes, they are viewed as techniques that may be
employed when needed to assure integrity and confi dentiality.
Enterprise Architecture (EA) (See Appendix B)
“A strategic information asset base, which defi nes the mission, the information necessary to
perform the mission, the technologies necessary to perform the mission, and the transitional
processes for implementing new technologies in response to changing mission needs. An
enterprise architecture includes a baseline architecture, target architecture, and sequencing
plan.”
A Practical Guide to Federal
Enterprise Architecture
Statement Of The Problem 9
ARTIFACT
“Any object made by a human with a view to subsequent use.”
Random House Dictionary
In practice, enterprise architecture is a collection of conceptual models, narratives, and “artifacts”
that collectively describe an enterprise as it operates today (“as is”) and as it is envisioned to operate
in the future (“to be”). Th e value of EA to the business is more than just its role in making IT invest-
ment decisions. Dynamic change in the business and technological environment coupled with the
consequent changes in business practice impose greater pressures for rapid response to these stimuli
than ever before. EA then, is considered the principle analytic tool to:
1. Understand and manage the extreme complexity of today’s technologically dependent organization.
2. Assure that uses of information technology are eff ectively aligned with the goals and objectives of the
enterprise.
3. Accelerate the effi cient design of new and modifi ed enterprise systems.
4. Reduce the response time for making impact assessments, tradeoff analyzes, strategic plan redirections
and tactical system reactions resulting from changing business conditions.
To assure the alignment of information technology with organizational goals and objectives, “data”,
“process”, and “communication” blueprints are created to guide the construction of systems that satisfy
the requirements of the business activity. In the course of defi ning an EA, vast amounts of information
about the business and its operating environment are captured and software tools are necessary to
manage and maintain this knowledgebase.
THE THREE CHALLENGES – CONSIDERED
Since the information needed to deal with each of the three challenges is found in a thorough under-
standing of the enterprise; the use of EA techniques and the Security Knowledge Framework eliminate
much of the duplication of eff ort that results when each challenge is tackled separately using existing
analytic methods. Additionally, the EA/SKF approach also identifi es previously unknown interde-
pendencies between challenge areas, and greatly improves the coherence, cohesion, eff ectiveness, and
defensibility of a course of corrective action. Before exploring how solutions to each challenge area lie
in the execution of the EA/SKF approach and the development of the Enterprise Security Architecture
(ESA); let us become more familiar with each of the challenges impacting the enterprise.
CHALLENGE #1: RENEWED EMPHASIS ON CORPORATE GOVERNANCE
After years of being alerted to fraud, waste, and abuse in automated government systems and following
the high profi le scandals at Enron, WorldCom and numerous other corporations where irregular ac-
counting and other questionable practices contributed to a stock market overvaluation and subsequent
devaluation of trillions of dollars; new guidelines and rules on corporate governance and IT manage-
ment have been formulated in both the U.S. and Europe.
10 Enterprise Architecture and Security Integration
Of great interest to U.S. corporations are the recently published Security and Exchange Commission
rules requiring accounting fi rms to certify that the companies they audit have adequate measures
in place to detect fraud. Required by the Sarbanes-Oxley Act, corporate governance rules call for
accountants to look behind the numbers at the fi nancial reporting systems that produced them and
certify in writing that they are adequate. Th is is most signifi cant as Michael Young, partner in the law
fi rm Wilkie Farr and Gallagher, describes “Th is is a landmark step forward in the evolution of fi nancial
reporting …Up to now, auditors have not been ordinarily asked to provide positive assurance on internal
controls. Now that they have been asked to do so, we can expect much more rigorous scrutiny of companies’
internal control systems as part of eff orts to root out fi nancial fraud.”
Financial controls include the checks and balances – generally executed by sophisticated computer
systems – which companies must now assure, are operating correctly in order to certify that their
fi nancial statements are properly prepared and are accurately representative of business conditions
within the corporation. For example, such controls should make sure that when a company records
a sale and reports revenue that it has a contract in place for the sale, that a customer has accepted the
goods, and that inventories have been adjusted accordingly. Th is calls for the in-depth examination of
their sophisticated computer system for both adequacy of design and security of operation.
For the Federal Government, the passage of several laws and regulations over the past years is having
a direct and signifi cant infl uence on the management of all automated systems that support agency
activities. Certain laws are especially meaningful to this discussion for their clarity of defi nitions and
directness of statement of offi cial responsibilities.
Th e most important include:
• Th e Information Technology Management Reform Act (Clinger-Cohen), 1996 created the offi cial position
of Chief Information Offi cer (CIO) and tasked them with creating an environment from which high qual-
ity, cost-effi cient, secure e-government will fl ow. Th is means that CIOs are responsible for introducing “best
practices” to their agencies and for insuring they are utilized. Clinger-Cohen also mandated that each federal
agency develop an Enterprise Architecture.
• Th e Computer Security Act of 1987, required the development of agency Security Plans and tasked the
National Institute of Standards and Technology (NIST) to provide “best practice” guidance.
• Th e Privacy Act of 1974, established record keeping (i.e. accuracy, timeliness, relevance, etc.) and confi den-
tiality requirements for federal agencies that collect and maintain individually identifi able data on citizens.
Th is law established early “due diligence” standards for the selection, implementation, and enforcement of
technical and administrative safeguards for personal data based upon “appropriateness”. A determination of
“appropriateness” required an assessment of risk to the accuracy and confi dentiality of records and the harm
that could accrue to the individual citizen should record integrity or confi dentiality be compromised. Th is law,
though rarely acknowledged, is still ineff ective.
• Presidential Decision Directives requiring federal agencies to evaluate security threats to their critical informa-
tion infrastructures and take corrective action to include creation of continuity of operations plans.
• Th e Federal Information Security Management Act (FISMA) – 2002 establishes a framework for annual IT
security reviews, reporting, and remediation planning. Importantly, FISMA adopted the defi nition of in-
formation assurance for its’ statutory purpose to mean “protecting information and information systems from
unauthorized access, use, disclosure, disruption, modifi cation, or destruction in order to provide
• (A) integrity
• (B) confi dentiality
• (C) availability
Statement Of The Problem 11
in systems used by an executive agency directly or by a contractor under contract with the executive agency.”
FISMA further requires the maintenance of an inventory of major systems, the annual testing and evaluation of
security controls, and the continuity of system operations.
It must be noted that duplication exists across these documents. Each has expressed the concerns of
congress or the administration at the time they were written, but it should be pointed out that each
embodies the following basic information management principles.
First, information is considered to be an organizational asset on a par with other physical assets
such as equipment, facilities, and people and must therefore be managed with the same degree
of discipline. Second, decisions concerning information and its collection, processing, storage,
safeguarding, and disposition are equally important to other decisions required of senior offi cials.
Th ird, information’s integrity and confi dentiality are considered fundamental to sound information
systems management and that the “appropriateness” of controls need to be determined based on risk
and the potential for harm should integrity and confi dentiality be breached.
In 1999, in the United Kingdom, Th e Institute of Chartered Accountants (England and Wales)
published, Internal Control – Guidance for Directors on the Combined Code. Known as the
Turnbull Report named for Nigel Turnbull who chaired the Internal Control Working Party; the
report states that: “Th e board should maintain a sound system of internal controls to safeguard
shareholders’ investment and the company’s assets” and that “… Directors should, at least annually,
conduct a review of the eff ectiveness of the group’s system of internal control and should report
to shareholders that they have done so. Th e review should cover all controls, including fi nancial,
operational and compliance controls and risk management.” For most UK corporations then,
providing assurances that internal controls exist and are eff ective (i.e. can be trusted) calls for the
in-depth examination of their sophisticated computer systems for both adequacy of design and
safety of operation.
Also, in 1999, the Organization for Economic Co-operation and Development (OECD) published
the OECD Principles of Corporate Governance. In the Preamble appears the following:
“One key element in improving economic effi ciency is corporate governance, which involves
a set of relationships between a company’s management, its board, its shareholders and other
stakeholders.”
“In creating this set of relationships, the board should fulfi ll certain key functions, including,
ensuring the integrity of the corporation’s accounting and fi nancial reporting systems, including the
independent audit, and that appropriate systems of control are in place, in particular, systems for
monitoring risk, fi nancial control, and compliance with the law.” And this, “Monitoring the eff ective-
ness of the governance practices under which it operates and making changes as needed”. Finally, “In
order to fulfi ll their responsibilities, board members should have access to accurate, relevant and timely
information”.
As in the case of US and UK corporations, for OECD members to provide assurances that
internal controls exist and are effective (i.e. can be trusted), calls for the in-depth examination of
their sophisticated computer systems for both adequacy of design and safety of operation. After
decades of “auditing around the computer”, governance guidelines now require that organiza-
tions establish programs to “audit within and through the computer” with boards of directors
certifying the validity and veracity of those audits. Clearly, this mandate will require a more pro-
active and holistic approach to the auditing and securing of systems in the computer-dependent
enterprise.
12 Enterprise Architecture and Security Integration
CHALLENGE #2: INCREASING CONCERN ABOUT ENTERPRISE VULNERABILITIES TO
E-BUSINESS SECURITY THREATS
During the past decade, there has been growing awareness that a lack of security poses great threats to
our increasingly computer dependent methods of conducting business and carrying out the functions
of government. E-business security incidents and attacks threaten the “trusted for use” criteria because
the integrity, confi dentiality, and availability of systems are being deliberately or accidentally accessed,
modifi ed, or destroyed by such incidents thus rendering the system untrustworthy. Numerous surveys
conducted by the private sector and federal law enforcement agencies show a steady increase in both
the number of incidents and in the sophistication of cyber-security incidents and attacks. For example,
according to the national Computer Emergency Response Team Coordination Center (CERT/CC) at
Carnegie Mellon University, the number of reported security incidents/attacks handled by the Center
has risen at a rate of over 200 percent a year since statistics were fi rst gathered in 1997. Currently, we
are witnessing an even greater increase and damage is becoming more widespread. Whole systems and
networks are being shut down for hours and even days, resulting in the loss of billions of dollars in
revenues. Recent surveys place the average loss per incident at over $250,000 per respondent orga-
nization. Other surveys indicate that external attacks are increasing at an alarming rate. Responding
companies have experienced an increase in penetration attacks upwards of 200 percent per year since
the year 2000.
Sophistication of attacks is increasing as well and they are becoming stealthier. According to Alan
Paller, Director of Research for the SANS Institute, “Th ere is a steadily increasing number of these
attacks. And there are more of these that have three characteristics that set them apart. Th e fi rst is that
attacks are coming simultaneously from multiple, coordinated sites. Th e second is that the attacks
are coming with more stealth, escaping the detection of intrusion detection monitoring systems by
limiting the number of ‘pings’, or connections. Th ese are coming in just under the detection threshold,
at one every hour, or every three days. Th ird, they are coming from patient people, who are usually
more professional than children.”
Ease of attacks has been increasing as well, due largely to the widespread availability of intrusion
tools and “exploit scripts” of known methods of attack that are shared by way of the Internet. Today,
absolutely anyone can attack a network. Incidents of computer crime are also increasing in record
numbers. Computer crime involves using computer systems to commit fraudulent acts or to destroy,
steal and/or illegally modify the legitimate information of a corporation or private citizen. According
to the School of Criminal Justice-Michigan State University, the percentage of major corporations that
reported computer crime over the past fi ve years is as follows:
• Credit card fraud – 96 percent
• Telecommunications fraud – 96 percent
• Unauthorized snooping of fi les – 95 percent
• Unlawful copying of software – 91 percent
At the same time, the FBI continues to claim that over 70 percent of computer crimes originate
with the “trusted” insider who has some degree of authorized access to corporate information and
processing systems.
In summary, the universe of threats facing computer dependent organizations involves three
types. First, are threats to the integrity of data/information, software, and computer processing and
Statement Of The Problem 13
communicating that prevent their being “trusted for use”? Second, are threats to the confi dentiality
of corporate information, processes, and customer/citizen data which violate the “trusted for use”
design specifi cation. Th ird, are threats to the availability of automated information and computer
processing systems that prevent their use when needed to conduct the authorized business of the
enterprise? Th ese threats have become especially serious for organizations that conduct on-line, 24x7
operations where “the business is the system” and constitutes a violation of the “trusted for use”
design specifi cation.
Identifying and countering such threats requires extensive knowledge of business operations, infor-
mation assets and systems, and those weaknesses which, occurring naturally or through exploitation,
are likely to result in a loss of integrity, confi dentiality, or the availability of computing capabilities to
operate the business of the enterprise.
CHALLENGE #3: POST 9/11 DEMANDS TO PROTECT CORPORATE AND NATIONAL
CRITICAL INFORMATION INFRASTRUCTURES (CIP)
Closely related to Challenge #2 is the broader governance and societal implication of our ever-growing
dependency on information technology and the many methods of communicating. America and
Europe’s critical information infrastructures are the foundation of western economies, national security
and quality of life, and yet these infrastructures, as has been pointed out by many studies and audits,
are amazingly open to malicious and accidental disruption.
As pointed out in 9/11 Commission Report, this creates a new dimension of vulnerability that,
combined with an emerging array of threats, poses a new set of risks to a nation’s security and eco-
nomic power. Potential adversaries – be they nation-states, cyber-terrorists, criminal organizations or
disgruntled employees – can easily develop attack capabilities to exploit these vulnerabilities.
Th ere are also the threats embodied in Pogo’s famous observation, “we have met the enemy and they is us” – threats caused by operational ignorance and incompetence, poor system design, insuffi cient
testing, fl awed implementation, inadequate training, and system mismanagement. An example still
fresh in everyone’s mind is Y2K – a well publized threat stemming from poor design and inadequate
documentation made worse through procrastination to become a virtually “show stopper” and budget
buster.
In the United States, recent administrations have supported the Partnership for Critical Infrastructure
Protection (PCIP) jointly sponsored by the Department of Commerce, the U.S. Chamber of Commerce,
and the Department of Homeland Security. To develop a national approach, major industry sectors
have been identifi ed as being “critical” to the nation and the economy – defense, energy, fi nancial
services, law enforcement, transportation, health care, vital government services, and information and
telecommunication services. To the extent that corporations are members of a “critical” industry sec-
tor, they are becoming more active with the PCIP eff ort and are taking steps to improve the security
posture of that portion of the infrastructure for which they are responsible.
In all cases, the majority of businesses having a “critical” sector role are fi nding that their “weakest”
link is something over which they may have little infl uence and almost no control – the products and services provided by the communications and computer services industry. Th is is true, even when “in-house”
departments administer computer services, because of their near total dependence on commercial
package software and the Internet to provide cost-eff ective (although insecure) communications. All of
the security problems embodied in challenge #2 adversely impact the requirement to secure corporate
14 Enterprise Architecture and Security Integration
and national “critical” information infrastructures and consequently challenge #3 can’t be solved until
substantial progress is made with #2.
THE REQUIREMENT TO DETERMINE “APPROPRIATENESS”
Common to each of the three challenges is the task of defi ning a course of IS/A action based upon
a determination of “appropriateness” or suitability. Th is requirement, which is clearly stated in
government regulations, and less so in industry guidelines and standards, deals with the question
of risk and the role of risk analysis in determining the ICA policies and controls to be placed on a
system or collection of systems. A clear understanding of potential risk is also necessary to formulat-
ing the structure and staffi ng of cost-eff ective programs of IS/A implementation, monitoring, and
maintenance.
For example: Sec. 3534 (a)(1)(A) of FISMA “provide information security protections commensurate
with risk and magnitude of harm resulting from unauthorized access, use, disclosure, disruption, modifi ca-tion, or destruction of …”
Also, the Privacy Act of 1974 requires that adequate safeguards be employed based upon an analysis of the “harm that may result” from a breach of confi dentiality or the making of an “adverse determination”, concerning an individual, based upon inaccurate, irrelevant or untimely information.
Satisfying these and other vaguely stated risk-based requirements demand the performance of a
penetrating risk analysis of the potential vulnerabilities facing the business, its’ technologies, and the
information systems of the enterprise. Th is analysis provides the basis for rational IS/A decisions. To
achieve eff ective and cost-effi cient protection, risk analysis is best performed within a framework of
“holistic” knowledge about the business and the environment – the type of information that is best
gathered and documented using an EA and SKF approach.
RISK MANAGEMENT – A GENERIC MODEL
A generic risk management model is comprised of eight steps: (1) value analysis, (2) threat identifi ca-
tion analysis, (3) vulnerability analysis, (4) risk analysis, (5) risk assessment, (6) management decisions,
(7) controlled implementation, and (8) eff ectiveness reviews.
1. Value Analysis is conducted to determine the importance of business processing to the corpora-
tion. Th is analysis takes into account the value and sensitivity of data, information, automated, manual
processes, and the value of computing assets to include software, hardware, and communications
equipment. Value is also placed on documentation and system “artifacts” that describe the “what” and
the “how” of system operation. Historically, the lack of comprehensive value analyzes has led to the
under capitalization of most IS/A eff orts.
Although previously ignored, the worth of systems documentation and “artifacts” are of fundamental
importance for achieving a balanced valuation of the total infrastructure needed to support a business
system. Adequate funding to sustain an eff ective IS/A eff ort can only be realized if such in-depth value
studies are performed. Th e Security Knowledge Framework (Part Two) was specially designed to facilitate the capture and analysis of “valuation” data. For additional discussion of this topic, see Compliance
Element #2: Adequate Capitalization – Chapter One.
Statement Of The Problem 15
2. Th reat Identifi cation Analysis is performed in two steps. Th e First, is the identifi cation of possible
threat agents to include authorized users, hostile agents, and environmental factors. Secondly is the
identifi cation of techniques that could be employed by a threat agent or triggered by an environment
factor that would result in an undesirable action or event. Breach techniques include attacks that are
perpetrated through physical, hardware, software, personnel or procedural means and/or through the
network or Internet. Th ere is an attempt at this stage to match possible threat agents with the means
available to them to mount an attack.
3. Vulnerability Analysis identifi es possible weaknesses in a system’s design, processing environ-
ment, physical facilities, or in any defenses that have been employed to protect it. Th is is a two-step
process. In the fi rst step, weaknesses or fl aws in the design, implementation, or operation of the
e-business system and its existing IS/A controls are identifi ed and then associated with a specifi c
threat identifi ed in step 2. In the second step, the vulnerabilities just identifi ed are ordered according
to potential seriousness, loss, and the probability of exploitation.
4. Risk Analysis is comprised of two major steps. First is an analysis of vulnerabilities. Th is means
that the various ways a threat (step 2) can exploit an identifi ed vulnerability (step 3) are fully analyzed
and documented. Th e second is the identifi cation of specifi c undesirable events such as unauthor-
ized disclosure or destruction of information, unauthorized manipulation of information or process,
unauthorized use of information or process, and/or denial of service. Each of these undesirable events
and their relationship to a threat are then documented.
Th is analysis forms the basis for a rational selection of ICA preventive and detection controls, and recovery procedures.
5. Risk Assessment determines the adverse impact should undesirable events occur. Th e primary
objective of the risk assessment is to evaluate the severity of risks and the adverse consequences cre-
ated by the combination of threats (step 2), vulnerabilities (step 3), their potential for exploitation,
and likelihood of the exploitation. Until recently, estimating costs for security breaches has been
more art than science. After years of research and consultation, the Gartner Group (www.gartner.
com) has published a model “Estimating Losses from an Infrastructure Compromise” that looks at
how a security breach aff ects the IT organization, IT staffi ng, corporate profi t, and clients. While this
is an improvement over past practices, the enterprise architecture paradigm requires an even broader
perspective.
6. Management Decisions are required as enterprise executives accept or reject risks that have been
identifi ed by the previous steps. Management then determines an appropriate course of IS/A actions.
First, a review is made of the assessment accomplished at step 5 to ensure that risks deemed acceptable
are indeed within tolerable limits. Risks that are determined to be unacceptable must then be miti-
gated either through the development of IS/A controls or through insurance. Th is is where “trusted
for use” design principles are to be employed (See Appendix A). Whether “new” systems are being
designed and developed or whether the existing portfolio of systems is being upgraded to improve
their functionality and IS/A profi le, the “trusted for use” design principles need to guide the eff ort. As
outlined in Appendix A, each of the principles is satisfi ed using any number of controls and safeguard
techniques and by employing commercial security packages of suffi cient strength to meet the ICA
demands of the system. At the conclusion of this phase of the risk management methodology, ICA
controls have been identifi ed, evaluated, designed and/or purchased for implementation within the
context of the acceptable risk profi le for the business systems in question.
7. Controlled Implementation synchronizes IS/A achievement with the implementation of “new”
system features and/or modifi cations. Th is plan requires a schedule, a budget, and necessary approvals
16 Enterprise Architecture and Security Integration
of management. Whether ICA controls and techniques are to be incorporated into a “to be” system’s
design or are to modify an existing system’s, the task of IS/A testing takes on great signifi cance. IS/A
tests and evaluations can be part of the existing Quality Assurance program or they can be conducted
as a separate independent validation, verifi cation, and test activity.
8. Eff ectiveness Reviews provide for the security Certifi cation and Accreditation (C&A) of imple-
mented IS/A controls in the operational environment of the enterprise system. C&A, which is formally
required of government systems, is also an acceptance of the ESA, as it exists within the larger EA.
RECONCILING COMMON DESIGN FEATURES WITH IS/A REQUIREMENTS
In addition to those threats and risk that are identifi ed through risk analysis, many systems are forced
to “trade-off ” proposed IS/A solutions to integrity, confi dentiality, and availability requirements against
other categories of system design characteristics that are often sought after in order to attain improved
“cost-effi ciencies”. Th e following features are commonly incorporated into the design of systems to
make them more “cost-effi cient”.
• Accessibility (i.e. more users equals lower overall cost)
• Interoperability (i.e. can speak to current and future systems)
• Flexibility (i.e. interface openness optimizes current investment)
• Portability (i.e. costs are kept low due to cross platform usage)
• Expandability (i.e. designed to ease expansion costs)
From an economic perspective, each of these features is often viewed by management as highly
attractive and vendors aggressively market their ability to provide them. But, these characteristics are
all too often in direct confl ict with the need to provide assurances of integrity, confi dentiality, and
availability. Th e confl ict exists because of inherent problems associated with the realization of each
feature as a measure of “cost effi ciency” in a system environment that is also tasked with being secure.
First, each characteristic is very diffi cult to specify. How is their achievement to be measured? Th ey
are too open with no real endpoint that can be defi ned except in the vaguest of terms.
• Accessible – by whom, to what, why, for how long, and for what purpose?
• Interoperable – with what, when, and where?
• Flexible – how? – when software must be precisely defi ned.
• Portable – in what environments and compatible with what standards?
• Expandable – how far, how wide, and in which direction?
Second, to be successfully implemented, each of these cost-effi cient features must have one thing in
common – the ability of the enterprise to plan for and then control their technology implementations
in accordance with those plans. Th is ability is often absent and can easily lead to the compromise
of IS/A solutions to defi ned ICA requirements. Th is is because the extent of managed control over
day-to-day operations, necessary to maintain a secure environment, is likely to be lost as accessibility,
interoperability, fl exibility, portability, and expandability features are exploited according to plans that
are incompatible with basic IS/A objectives. Without the analytic insights provided by the Enterprise
Architecture and its associated Enterprise Security Architecture there can be no satisfactory answers to
Statement Of The Problem 17
the questions previously asked of each cost-effi cient characteristic or their envisioned implementation
within an operational setting.
Th ird and perhaps the greatest danger posed by these seemingly desirable system characteristics
is that management can become overly enamored with their achievement, and may not understand
nor be aware of the “IS/A compromises” that are being made as “cost-effi ciency” becomes the driving
force behind systems design and implementation. For example, the characteristics of accessibility and
portability require an openness of architecture that is most likely counter to the more restrained design
approach required to achieve an adequate level of integrity, confi dentiality, and availability.
The Baseline From Which To Address Governance, Security and CIP Issue 19
THE BASELINE OF REQUIRED INFORMATION
Policy, procedural, and technology solutions to solve challenges #1, #2, and #3 fi nd their
“origins” and their “exclusive expression of requirements” in a clear understanding of the
business/mission activity of the enterprise and in knowing whether the processed information
representing those business activities can be “trusted for use”. While the elementary usefulness of
an information system is based on the assumed trustworthiness of its’ output; the very existence of
challenges #1, #2, and #3 call into question that assumption.
As discussed, to say that an information system has integrity is to assume that it can be “trusted
for use”. To have integrity, an information system must have been designed, developed, tested, and
validated to meet a set of documented criteria spelling out how “trust” is to be judged. To argue that
a system has “integrity” assumes that it is protected against the occurrence of errors, commission of
deliberate malicious actions, and acts of god. Integrity also requires that continuity of business activi-
ties be assured through the execution of deliberately formulated recovery plans.
To maintain that an information system is secure is to say that the integrity of the system and
the confi dentiality of its proprietary processes and information are being protected against accidental
mistakes and deliberately malicious acts. Protection is accomplished through non-technical as well as
technical means and is incorporated into the system during design and development – not “tacked on”
as an after thought. Th e knowledge baseline from which corporate governance and information system
security certifi cations can be developed must be based on an unambiguous understanding of what
constitutes integrity and confi dentiality for all data/information, each database, information processing
systems, and systems of communication – whether automated or manual. Additionally, the knowledge
baseline needs to include an equally clear understanding of what system availability requirements are
based on the nature of the business and what amount of downtime and processing disruption can be
tolerated. Th e dilemma confronted by most organizations is how to satisfy the demands of challenges
#1, #2, and #3 while working in an enterprise of decentralized yet inter-dependent business units; each
of which have spawned, over time, incompatible information systems, databases, and communication
networks with little attention given to ICA issues. Solutions to this reality will require innovative
thinking, an enterprise-wide perspective, and the formation of a “due diligence” perspective.
Chapter Two: The Baseline From Which
To Address Governance, Security and CIP
Issue
20 Enterprise Architecture and Security Integration
CHARTING A “DUE DILIGENCE” COURSE OF ACTION
Th ere are no absolutes with regards to integrity and confi dentiality and even the best-protected system
can be destroyed leaving its’ services unavailable through “act of god”, mismanagement, malfeasance,
or terrorist act. So how, in good faith, can an enterprise proceed with their eff orts to seek an accord
with the challenges presented by integrity, confi dentiality, and system availability? Th e Y2K experi-
ence of the last decade gives a clue. Y2K fi rst introduced business executives and boards of directors
to the notion of “due diligence” as it applied to the use of information technology. Because of the
potential for legal fallout, it became necessary to view Y2K-related decisions and actions through the
lens of assuring “due diligence” through the exercise of “reasonable care.”
Due Diligence: Th at degree of eff ort and care in carrying out an act or obligation that the average,
sincere, energetic person would exhibit – conduct that is devoid of negligence or carelessness.
Th e Plain-Language Law
Reasonable Care: Th at degree of care, which a person of ordinary prudence would exercise in the same or similar circumstances – failure to exercise such care, is ordinary negligence.
Black’s Law Dictionary
It became essential to document all Y2K deliberations, decisions, and actions in order to defend
against possible charges of laxity. It was necessary to demonstrate that “due diligence” and “reasonable
care” actions were taken to anticipate and prevent Y2K damage and that plans existed to recover from
Y2K damage should preventive measures fail. For present purposes, the signifi cance of “due diligence”
and “reasonable care” thinking is that they create an evolving metric against which an enterprise’s
adequacy of governance (internal controls and management), confi dentiality controls, and critical
processing responses can be compared. Such comparisons will invariably be with similar companies in
like circumstances of vulnerability and threat and with correspondingly predictable adverse impacts
on customers, business partners, investors, and perhaps the public. For example, if one company does
employ a type of ICA control and does not experience security breaches of the kind the control was
intended to prevent, that fact could be used to establish a possible “controls” baseline against which
similar companies could be compared. Th e same control action being taken by several similar compa-
nies could thus evolve into a de facto standard and be considered a “best practice” for other companies
in that particular industry to consider using.
Now, if another company in the same industry does not employ the same or equivalent ICA
control and does experience a security breach of the kind the control was intended to prevent, it
may be asked whether that company exercised “due diligence” or demonstrated “reasonable care” as
compared to the practices of like companies. It may well be that evidence of the analytic process used
by the company to support their course of action will be considered necessary; and that questions
of potential liability may be determined by whether or not the company acted in a prudent manner
when compared to its’ industry peers.
As a quasi-metric, “due diligence” and “reasonable care”, will evolve as technology, vulnerabilities,
threats, risks, and business practices change. Th is means that decisions and subsequently implemented
ICA measures to meet the demands of challenges #1, #2, and #3 are not one-time events, but must be
subject to a continuous process of risk re-evaluation and ongoing IS/A management.
The Baseline From Which To Address Governance, Security and CIP Issue 21
NECESSARY ELEMENTS OF A “DUE DILIGENCE” COURSE OF ACTION
Th ere are four elements that comprise a “due diligence” and “reasonable care” course of action for the
enterprise seeking to conscientiously deal with the technology management aspects of challenges #1,
#2, and #3.
ELEMENT #1: DEMONSTRATE SECURITY KNOWLEDGE MANAGEMENT – (A MAJOR
“VALUE-ADDED” PRODUCT OF EA)
Th e foundation of an eff ective program to manage the technological aspects underlying each of
the three challenges is the existence of complete and accurate inventories and a comprehensive
knowledge of all business systems, their information technology manifestations, and their manual
processing procedures. Th e principal objective of the four elements is to demonstrate that sensible
eff orts are being made to meet the “letter” and “intent” of applicable laws and guidelines and protect
the valuable assets of the enterprise. Reasonableness of action certainly cannot be demonstrated if
complete and accurate inventories of information, systems, hardware, software, networks and users
do not exist and a clear understanding of how they collectively function as enterprise systems is not
known.
Just how prevalent the lack of inventories is was recently expressed in a Harvard Business Review article written by Robert D. Austin and Christopher A.R. Darby (June 2003).
“Know exactly what software is running. It’s shocking how many companies don’t follow this very
obvious rule. Keeping track of what versions and fi xes have been applied is as fundamental to digital
security management as keeping an accurate inventory of physical assets is to plant management. We’re
not saying that this is easy … (but) it’s crucial to document every modifi cation.”
Note that this is the very same problem that existed at the beginning of Y2K remediation eff orts
and that most organizations spent a great deal of time and money creating just such inventories.
It would be interesting to check on the status of those inventories today.* Are they accurate? Are
they still being maintained? Has the enterprise institutionalized the mechanisms to keep such
inventories current? If not, then establishing them once again will have to be the fi rst step in
demonstrating that the enterprise is trying to act convincingly with regards to challenges #1,
#2, and #3. Should it become necessary to recreate accurate inventories, signifi cant amounts of
information about the business, its supporting technologies and manual systems must become
known (i.e. documented) and managed so as to remain timely and accurate. Th e fi rst step lies in
employing the analytic disciplines used to create an EA of data and processes and the models of
business systems from which specifi c “blueprints” for information and communication system
construction are developed.
* During the past 3 years, the author has made just such an inquiry of students attending the FEAC Institute. On only 2
occasions have students acknowledged that their organizations have maintained such inventories. Th is is indeed alarming since
the maintenance of EA repositories and existing “artifact” documentation dwarfs the data that was missing with regards to Y2K.
Th is represents a major disconnect between what we know is necessary to manage IT – and now EA – and what is actually going
on! Unless this disconnect is corrected through adequate funding and the enforcement of EA document maintenance, the eff ort
many organizations are now expending to create their EA will come to naught as operational systems lose synchronization with
the EA repositories – the window into the automated enterprise.
22 Enterprise Architecture and Security Integration
Th e exercise of “due diligence”, to demonstrate that a reasoned approach to IS/A problem resolution
has been taken, lies in providing evidence that ICA requirements are defi ned and have been included in
all appropriate documents and “artifacts” of the EA. Th is in turn, insures that the specifi cations needed
to build integrity controls and confi dentiality safeguards into each business process can be derived and
serve as input to design, programming, testing and fi nal security certifi cation. Th e Security Knowledge
Framework (SKF) assists greatly in this endeavor – Part Two.
ELEMENT #2: ADEQUATE CAPITALIZATION
It is important to realize that the greater part of what is required to bring about a successful resolution
to challenges #1, #2, and #3 is necessary because of an earlier laxity in the development and subsequent
life-cycle management of the vast majority of automated systems. For years the audit community, most
notably the US General Accountability Offi ce (GAO), have been pointing out the internal control and
security defi ciencies of both government and private sector systems. Instructional materials regarding
discovered defi ciencies along with corrective action guidelines have been numerous and yet, according
to the never-ending stream of audit reports from GAO, little progress seems to have been made. A
principle reason for this has been a lack of adequate funding for the development, maintenance, and
enforcement of internal control and security programs within organizations. Th is has often been due
to the belief that controls inhibit rather than enable the conduct of business – when the exact opposite
is true! Enter the aspect of cost/benefi t studies known as the Return on Security Investment (ROSI)
analysis.
Developing a ROSI is a diffi cult task that has been amply demonstrated by the fact that information
technology management and security eff orts have historically been under funded. In the past, most
security initiatives have been paid for with whatever “year end” money was available. Th is has resulted
in the piecemeal implementation of incompatible “point solutions” which do little to improve the
overall security posture of an enterprise.
Because of the three challenges facing the enterprise, serious questions have begun to be asked by
the “board” regarding the management of business risks in general and the economics of computer
integrity and confi dentiality controls in particular. Executives are questioning “what a pound of security
is worth”, and how to justify security expenses. Historically, the answer has been that the cost to secure
“hard” computing assets (i.e. hardware, software, facilities, communications equipment, etc.) should
be less than the annualized (i.e. over the expected life) replacement cost of those assets should they be
destroyed, stolen, made unusable, or lost.
Experience has shown however, that replacement costs can’t begin to fund a robust security eff ort
and this is because, the “hard” asset replacement approach does not account for the “soft” value-areas
of information loss, business interruption, loss of corporate reputation, and potential liabilities – areas
where the most substantial impact and worth of automated business systems actually lie. Th is inad-
equacy is due to the diffi culty experienced in determining a “value” for data, information, and the
business processing systems themselves. Until an enterprise can reach a consensus about the “value” of
its information and the “worth” of maintaining information and processing integrity, confi dentiality,
and systems availability, the “board” will be forever destined to argue over how much to spend for a
“pound of security” and little progress will be made!
Given the limitations of the “hard” asset replacement strategy, the generation of a ROSI, suffi cient
to assure adequate IS/A capitalization, needs to combine replacement cost calculations with a frank
The Baseline From Which To Address Governance, Security and CIP Issue 23
attempt to estimate the worth of investing in controls that assure the integrity, confi dentiality, and avail-
ability of business information and systems that are of value to the enterprise. Th is cannot be achieved
without a process for “valuing” the data, processes, communications, and other assets that support
the systems of the enterprise. In Part Two – “Th e Security Knowledge Framework” will introduce a
“valuing” process that is integral to the creation of the Enterprise Security Architecture.
Factors to consider when placing value on system assets and when calculating a ROSI:
1. Ideally, a ROSI should be seen as a positive “return of value” directly derived from the underlying Return
on Investment (ROI) being used to justify the system that is being protected. In other words, the dollars
to be expended on IS/A controls should be viewed as fundamental to achieving the ROI of the system
to which they apply. How much is a “pound of security”? Th e answer, how “valuable” is the information,
business process, and corporate reputation being protected. Without ICA being assured, the value of
the system is questionable for it may not be able to be “trusted for use”. Also, remember, that since
the implementation of many integrity and confi dentiality controls apply to a multiplicity of systems, the
expense is actually pro-rated over the number of systems being protected thus reducing the impact on any
one system.
2. With hacker-related insurance soaring – from $100 million to over $900 million in 2005 – a positive
ROSI may be calculated based on reduced insurance premiums as improved IS/A controls are applied
across the enterprise.
3. Revenue losses due to breaches of ICA requirements are becoming better documented. Th e following
averages of loss revenue can allow executives to estimate the potential for loss should their business face
system destruction or interruption of service. Th e average loss for 1 hour of time:
Financial – Brokerage Operations $6,500,000
Financial – Credit Card Sales $2,600,000
Media – Pay for View $ 150,000
Retail – Home Shopping (TV) $ 113,000
Retail – Catalog Sales $ 90,000
Airline Reservation Sales $ 89,500**
** Gartner Group & Contingency Planning Research
In addition to tangible dollar losses, there are many categories of loss that are “intangible” and, while
more diffi cult to estimate, they are more substantial, and must be considered if adequate funding is to
become a reality. For example, what is the “value” and “worth” of the following?
• Responsibility to business and “supply chain” partners.
• Loss of revenue “opportunities” due to lack of secured system infrastructure (i.e. don’t bother to bid unless you
are secure).
• Loss of customers due to lack of trust.
• Not being able to meet corporate obligations to support national CIP eff orts.
• Loss of corporate reputation.
• Potential liability.
24 Enterprise Architecture and Security Integration
In conclusion, the capitalization of IS/A eff orts must be suffi cient to not only implement compre-
hensive ICA solutions but to also fund the on-going administration and maintenance of a continuous
IS/A management process (see element #4) designed to institutionalize the enterprise response to each
of the three challenge areas.
ELEMENT #3: RISK MANAGEMENT
Th e third element of a “due diligence” course of action is to have the on-going ability to make ICA
control decisions based on the determination of risk, and the evaluation of possible control solutions
to determine their effi cacy and cost eff ectiveness. Because of extensive and intrinsic dependence on
computer technology, today’s enterprise requires a special type of analysis to uncover potential threats
to ICA and arrive at cost-eff ective preventive and/or corrective solutions. Whether this analysis is
conducted during the formulation of a new or “to be” system or whether it is performed on an existing
or “as is” system, the process must be systematic, disciplined, and based on sound risk management
principles.
As discussed in Chapter 1, risk management methodologies usually include the following eight
steps: (1) value analysis, (2) threat identifi cation and analysis, (3) vulnerability analysis, (4) risk analy-
sis, (5) risk assessment, (6) management safeguard decision, (7) controlled implementation, and (8)
eff ectiveness review. It can’t be emphasized enough, that the success of any risk management eff ort is
greatly dependent upon the comprehensiveness and accuracy of the Security Knowledge Management
System discussed as Element #1.
Th e success of a risk management methodology is also heavily dependent upon the quality of
vulnerability and threat “source” information. Knowledge about threat exposures is a constantly shift-
ing landscape and staying up-to-date requires the investment of personnel, time, and dollars. A risk
assessment performed in 2006 will not be the same as one performed in 1999 or even 2004 since
technology will have changed. And even if basic technologies are unchanged, hardware confi gurations
and business processes change constantly, even minute to minute – modifying the operating environ-
ment and hence the vulnerability and threat profi le. Until the requirements of EA to generate and
maintain an ESA, the best that could be done was to approximate the security posture of the enterprise
and its business systems. Now, with more accurate system and artifact inventories and the use of risk
management methods, approximations can be replaced by meaningful vulnerability and risk assess-
ments thus increasing the likelihood that integrity, confi dentiality, and availability controls will respond
to today’s threats and not yesterdays.
ELEMENT #4: AN IS/A MANAGEMENT PROCESS
In the fast changing world of today’s technology based business, a need exists to automate the EA, ESA,
and security knowledge management to seamlessly integrate:
1. All ICA requirements, documents and “artifacts” of the EA,
2. Data, information, process, and “hard/soft” valuation data,
3. Applicable threats and risks,
The Baseline From Which To Address Governance, Security and CIP Issue 25
4. Known and suspected vulnerabilities (taken from subscription sources, corporate intrusion detection
systems, and vulnerability/threat assessments),
5. Business policies, and
6. All active integrity/confi dentiality control implementations and those precautions taken to provide system
availability.
Th e IS/A Management Process should make this information available to enterprise decisions makers
for the enforcement, monitoring and the overall improvement of ICA controls as required by changing
business requirements, “new” emerging threats, and “due diligence” strategies.
Th e operational elements of a permanent IS/A Management Process include the following
components.
IS/A Policy Management: Th e policy management component enables organizations to import
or create security policies based on ISO, NIST, or industry-unique standards, distribute them
on-line, educate and train employees and track compliance, exceptions, and violations. For
federal government agencies, this capability would greatly ease the reporting requirements of
FISMA. In practice, this module needs to be linked, as an integrated extension, to the EA
repository so as policies change, upon analysis, their impacts will be refl ected in the appropriate
EA and ESA document or “artifact”.
Th reat Management: Th is provides organizations with a proactive approach to the management
of threats aff ecting information and technology assets by notifying users of vulnerabilities when
they become known and by providing down-to-the-keystroke implementation procedures for
securing existing computing assets. Organizations can either author or import vulnerability and
safeguard information from security associations, special interest groups, or a vendor of their
choice. Th e threat management module would be comprised of:
• Vulnerability library
• Subscription to real-time vulnerability data feeds
• Implementation procedures library
• Filtered “alert” notifi cations
• Implementation work plans
• Online technical training
Infrastructure Management: Th is allows organizations to manage the process of determining the
proper ICA solution (patches, fi xes, updates, backups, and procedures) to be implemented on
specifi c infrastructure assets based on use, vulnerability, and risk to the enterprise. It provides an
integrated task management system that alerts system users when new tasks have been assigned
to them and provides information about the impact that task will have on system assets for
which they are responsible and instructions on implementing adequate ICA controls.
26 Enterprise Architecture and Security Integration
Knowledge Management: Th is allows organizations to dynamically create new components for
the collection and distribution of ICA vulnerabilities and safeguard solutions unique to the
enterprise. Th is capability makes possible the tailoring of ICA solution-sets to specifi c enterprise
business application areas and unique business or vendor support agreements. In other words,
the creation of a tailor-made IS/A Management Process complete with content for unique en-
terprise business domains, supply chains, or outsourcing arrangement.
CONCLUSION
According to Peter Drucker in Management Challenges for the 21st Century (2001), change has be-
come the norm and the job of executives is to lead change. Drucker writes that “Being a change leader
requires the willingness and ability to change what is already being done just as much as the ability to
do new and diff erent things.” Th e time has come to change the methods of information technology
governance and the security of enterprise information systems. Clearly, the authors of laws and regula-
tions dealing with challenges #1, #2, and #3 expect such change. Just as clearly, the authors expect that
information technology systems be managed with the same degree of discipline and rigor that is taken
for granted in other areas of the enterprise.
While these tasks may seem formidable, they are possible; but will require the commitment and
dedication of senior executives and the “board” to make them happen. Remembering Einstein’s adage
that “problems cannot be solved by the same level of thinking that created them”; new thinking and
new tools are needed. Part II introduces the Security Knowledge Framework (SKF); a methodology
that is signifi cantly infl uencing the design of future information systems. Its use will assure the creation
of an Enterprise Security Architecture that is integral to, and consistent with, the architecture of the
enterprise. Th is, in turn, will insure that the IS/A business requirements for integrity, confi dentiality, and
availability are being defi ned, documented and developed through the application of sound systems
development and IS/A “best” practices.