Enterprise Architecture and Security Integration

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,


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


“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


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.


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


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.


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


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


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.


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


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


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


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.


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.


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


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.


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,


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.


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.

Enterprise Architecture and Security Integration

Documents

Transcript of Enterprise Architecture and Security Integration