Enterprise Information Security Program - Alberti

7/27/2019 Enterprise Information Security Program - Alberti

http://slidepdf.com/reader/full/enterprise-information-security-program-alberti 1/74

Enterprise Information Security Program Design 1

En t e r p r i se I n f o r m a t i o n Se cu r i t y P r o g r a m D e s i g n

Robert Alberti

BSc Information Security Management, CISSP, ISSMP

Book Draft

October 18, 2013




1 Introduction.................................................................................................................................................4 1.1 The structure of this book ..................................................................................................................5 1.2 Business and Security .........................................................................................................................5

2 What is Security?.........................................................................................................................................6 2.1 C‐I‐A ....................................................................................................................................................6 2.2 Authentication ................................................................................................................. ...................9 2.3 Authorization .................................................................................................................. ................. 12 2.4 Trust................................................................................................................................................. 16 2.5 Review.............................................................................................................................................. 17

3 Defense in Depth...................................................................................................................................... 17 3.1 Software........................................................................................................................................... 18 3.2 Platforms.......................................................................................................................................... 19 3.3 Databases......................................................................................................................................... 20 3.4 Network ........................................................................................................................................... 20 3.5 Assurance......................................................................................................................................... 21 3.6 Research methodologies ................................................................................................................. 22 3.7 Knowledge creation......................................................................................................................... 22

4 Strategic Elements of an EISP................................................................................................................... 24 4.1 Organizational

Structure

and

Reporting.......................................................................................... 24

4.2 Principles.......................................................................................................................................... 26 4.3 Project Charter................................................................................................................................. 26 4.4 Enterprise Leadership ...................................................................................................................... 26 4.5 Business Leadership......................................................................................................................... 27




4.6 Business drivers ............................................................................................................................... 28 4.7 Maturity ....................................................................................................................... .................... 32

5 Tactical Elements

of

an

EISP..................................................................................................................... 32

5.1 Information Security Standards....................................................................................................... 33 5.2 Information Security Processes ....................................................................................................... 37 5.3 Information Security Techniques..................................................................................................... 46 5.4 Information Security Promotion, Awareness, and Training ............................................................ 49 5.5 Information Security Policies........................................................................................................... 50

6 Operational Elements

of

an

EISP.............................................................................................................. 56

6.1 Tracking and Knowledge Creation ................................................................................................... 57 6.2 Operational requirements ............................................................................................................... 57 6.3 Firewall Configuration and Change ................................................................................................. 58 6.4 Compliance vs. “Real” security ........................................................................................................ 60 6.5 Security Assessment ........................................................................................................................ 60

7 Conclusion ................................................................................................................................................ 61 8 Appendix A. EISP Project Charter ............................................................................................................. 61 9 Appendix B. Example EISP ........................................................................................................................ 62 10 Appendix C. Security Assessment Framework ..................................................................................... 62 11 Appendix D. STAR Template................................................................................................................. 62 12 Appendix E. Badges and UserIDs.......................................................................................................... 62 13 Appendix F. SAML Request .................................................................................................................. 65 14 Bibliography ......................................................................................................................................... 71




Enterprise Information Security Program Design:

Book Draft

Robert Alberti

1 I n t r o d u c t i o n

The need for improvement in information security is obvious, and stories of security incidents are daily

features in the news (Lee, 2011). On any given day, the British Information Technology (IT) trade journal ‘The

Register1’ features more than a dozen stories of malware, viruses, credit card information losses, and

exposures of personal health information. The FBI estimates of losses to business due to security incidents

grew from $130 million dollars in 2005 (Hahn & Layne‐Farrar, 2006), to $37 billion in 2011 (Snow, 2011). This

phenomenal increase is due to increases in mandatory reporting (Mehalko & Pulliam, 2011) and the increase in

organized (Rodriguez, 2011) and even state‐sanctioned cybercrime (Talbot, 2010).

Despite the threat of security incidents and the possibility of regulatory penalties faced by some

enterprises, businesses have struggled to improve the security of their information systems (IS) with limited

success. While frustrating, this is understandable: business processes change slowly – sometimes too slowly for

a given business to survive when its environment changes. In the geologic timescale of business change

computers are still a quite new addition to the workplace, with workstations and client‐server architectures

barely more than twenty years old, and smartphones less than ten. A century from now (assuming civilization is

uninterrupted by cataclysm) business processes will probably have adapted to employ such things in well‐

understood processes taught in collegiate masters programs, but business is still reeling from the introduction

of these devices. Information which thirty years ago could be secured in locked file cabinets now invisibly

escapes the office over radio signals, or is smuggled out in a USB drive

hidden in a pen (Figure 1).

This goal of this book is to introduce the framework of an Enterprise

Information Security

Program

(EISP)

for

a mid

‐sized

or

large

organization.

Its intended audience is tactical‐level information security management:

either the Security Manager of a small company (one with less than 100

employees), or the Chief Information Security Officer (CISO) of a mid‐sized

1 http://theregister.co.uk/security

Figure 1. USB Pen




or large corporation (with more than 100 employees). This management level is well‐positioned to influence

the security of sensitive information in a corporation through an EISP that augments technical solutions with

policy and process changes and awareness programs. The information also applies to smaller businesses, but

these will have both fewer resources to dedicate to such efforts, and are also subject to fewer due to the rich

availability of larger targets for information security threats.

It is hoped that by introducing the factors that contribute to the development of an EISP this book can

contribute to the necessary dialog towards building the business practices which will be taken for granted by

business students a hundred years from now.

1.1 The structureof thisbook

This

book

describes

the

factors

that

comprise

information

security

itself,

followed

by

an

exploration

of

the

concept of Defense in Depth (DID) the distribution of security controls across multiple layers of the network.

The strategic, tactical, and operational elements of the Enterprise Information Security Program are described,

and samples of the primary documents that comprise an EISP are provided as separate appended documents.

Finally, technical descriptions too detailed for the main body of the document are included as appendices.

Throughout this document, the term “enterprise” is used to describe the organization in question, since

the concepts apply to corporations, groups, nonprofits, or any undertaking that manages electronic

information.

1.2 Businessand Security

The integration of business processes with information technology (IT) is far from complete and is likely to

remain in flux for another generation. Only when the majority of business leaders have grown up with

computer technology, from grade school classroom through corporate workstations and on to the boardroom,

will a “critical mass” of senior business leaders such as board members, presidents, C‐level executives have the

comprehensive understanding of the function and impact of computers in the workplace to make the strategic

decisions necessary to effectively implement information technology in an efficient and secure fashion.

While the fundamentals and theories of computer technology underlie all information security solutions,

business leadership is essential to drive the comprehensive organizational change necessary to promote the

awareness that can assure the security of an organization’s sensitive information.

Sensitive information is any information controlled by an enterprise that is not intended for access by the

general public for competitive reasons, or because the information is being held in trust for clients or partners.




Examples include electronic patient health information (EPHI), customer credit‐card information, and business

partner competitive information (e.g. purchases from a manufacturer by two competing resellers).

An EISP is the collection of all standards, policies, procedures, techniques and training required to both

secure the sensitive information handled by an enterprise and meet all legal requirements and industry best

practices regarding the handling of sensitive information. The creation of an organization’s first EISP will have a

profound impact on how the organization does business, the “organizational culture.” Cultural change of such

magnitude requires skilled leadership if the program is to be both enduring and effective in securing sensitive

information.

Securing the sensitive information handled by an enterprise is a separate task from that of meeting all legal

requirements and regulations regarding the handling of sensitive information. It is entirely possible to meet all

legal and regulatory security requirements to which an organization is subject without actually making the

information secure. It is possible to make the information handled by an organization quite secure while failing

to meet the full requirements of law and regulation. An Enterprise Information Security Program must balance

both of these goals against the need for the enterprise to conduct its operations efficiently and affordably.

2 W h a t i s Se cu r i t y ?

Before setting forth to develop an Enterprise Information Security Program, it makes sense to devote some

attention to

defining

what

security

actually

is.

This

is

an

important

question

which,

if

left

unanswered,

leads

to

such disasters as the United States Transportation Security Authority (TSA), which costs immense amounts of

money and arguably does nothing at all to increase security (Goldberg, 2008). This is because the trappings of

security were rolled out without defining what the meaning of “security” was in a post‐9/11 transportation

environment. Noted information security specialist Bruce Schneier famously coined the term “security theater”

to describe the product of the TSA’s efforts (Schneier, 2003).

Any organization that wishes to be successful in establishing a successful security program must first define

both

“success”

and

“security.”

We

will

look

more

closely

at

these

topics

after

we

have

reviewed

the

fundamental elements that comprise security.

2.1 C ‐I ‐ A

The acronym that describes the three main components of security is CIA, “Confidentiality, Integrity,

and Availability,” (Gollmann, 1999, p. 5) which emerged in turn from the World War II era cryptanalysis




concepts of security threats of “information recovery, manipulation of information, denial or degradation”

(Anderson, 1972, p. 58).

2.1.1 Confidentiality Confidentiality, the prevention of unauthorized disclosure of information, is divided into two categories:

the term privacy applies to personal information, and the term secrecy to organizational information. These

two aspects of confidentiality can and do come into conflict. For example, corporations or governments that go

to great lengths to protect the secrecy of their operations may also handle customer or citizen information in a

way that violates those customers’ privacy. Requests under the United States Freedom of Information Act

(FOIA) often seek to breach official secrecy in order to ascertain violations of personal privacy. (Electronic

Freedom Foundation,

2011)

Prior to the digital age, confidentiality could be maintained largely through physical security – picture the

Cold War era spy photographing papers extracted from a wall safe, or a World War II counterpart smuggling

microfilm out of the Reichstag – but the advent of digital information profoundly changed the landscape of

threats to confidentiality. Computers not only have to be designed not to allow unauthorized users to read

confidential information, but for instance must be designed to never write confidential information into an

insecure location where it could later be vulnerable to reading by some other system. The Minneapolis based

Internet Service Provider (ISP) named Glasspath (long since absorbed by another) demonstrated the profound

misunderstanding between pre‐ and post‐Internet security when it bragged that its data center was more

secure because it “…resides in an actual vault with 21 inch thick concrete walls reinforced with steel and 4-ton

functional steel vault doors” (Glasspath, 2001). Once data signals could be transmitted through those concrete

walls, the vault’s existence became moot to the security of the data within.

Much of the early work in computer security involved the design and mathematical proof of security

models for the protection of confidentiality. For example, the Bell‐LaPadula confidentiality model (Bell &

LaPadula, 1973) describes a set of controls that prevent unauthorized reading and writing across “security

levels,” subsections

of

computer

memory

and

storage

that

have

different

security

requirements.

Bell

‐LaPadula

can be described as “no read up, no write down,” where “up” refers to a more confidential security level. These

two rules are known as the Simple Security Property (“no read up”), and the ★‐Property (pronounced “star

property,” the “no write down.”) While these properties can help protect confidentiality, they fail to protect

the next security principle, Integrity.




2.1.2 Integrity While Bell‐LaPadula protects confidentiality by restricting the movement of secure information from higher

to

lower

security

levels,

it

leaves

open

a

threat

to

integrity.

Integrity

is

when

information

is

in

its

intended

state

and has not been altered without authorization. More broadly, integrity refers to the trustworthiness of system

resources over their entire life cycle. Where the Bell‐LaPadula ★‐Property fails to protect integrity is by

allowing “write‐up” from a lower security level to a higher one.

One of the premises upon which the Biba integrity model rests is the concept of confidence (Jaeger, 2008),

the idea that the higher its integrity level, the more trustworthy is the information. Therefore writing up from a

lower integrity level to a higher integrity level must be prohibited in order to maintain the trustworthiness of

data at the higher integrity level. The Biba Simple Integrity Axiom can be stated as “no read down,” to prevent

moving low‐confidence data into a high‐confidence zone, and the Biba ★‐Integrity (“star integrity”) Axiom, “no

write up,” prevents lower levels of integrity writing up to higher levels for the same reason.

Combining Biba integrity axioms with Bell‐LaPadula confidentiality properties yields the following (Table 1):

Table 1. Combined Confidentiality and Integrity

Goal Going UP (Reading from Above or

Writing from Below)

Going DOWN (Writing from Above

or Reading from Below)

Confidentiality (Bell‐LaPadula) OK NO

Integrity (Biba) NO OK

So when

the

goal

is

to

both

maintain

integrity

AND

confidentiality,

no

movement

of

data

is

allowed

across

security levels, requiring the use of firewalls between parts of a network with different security levels.

2.1.2.1 Strong★‐Property

There is also a remaining confidentiality property which parallels a Biba integrity axiom. If data in the

higher security level is supposed to be confidential – private or secret – then allowing writing from a lower level

to a higher level means that the author of the information, an author at a lower Confidentiality level, knows

what is stored in the higher security level… because the author wrote it. The variant of Bell‐LaPadula designed

to prevent this phenomenon is called the “Strong ★‐Property” (pronounced “strong star property”) and

further limits both the reading and writing of information to a single security level. This property is identical in

function if not in intent to the Biba ★‐Integrity Axiom. The implications of this property are important. For

example, an author could write information up into an area of U.S. government secrecy that requires a

Freedom of Information Act (FOIA) request to gain access. By writing false information (an integrity breach) or

incriminating evidence (a secrecy breach) the author could then issue a FOIA request to retrieve it. Now the




author can claim the government was hiding the information, which the government did not know it

possessed.

2.1.3 Availability Availability means assuring authorized access to data. Threats to availability range from theft of a laptop to

a fire in a data center to a distributed denial of service (DDOS) attack employing a large number of computers

to overwhelm Internet access to a particular network site. While both Confidentiality and Integrity can be

threatened through a physical vector (as part of a security audit I once used binoculars to spy on a third‐floor

data center of a Fortune 50 company from a parking ramp across the street), physical threats to availability

seem particularly abundant.

There are

a number

of

reasons

that

this

is

the

case.

First,

it

is

usually

easier

and

simpler

to

disable

something than to gain illicit access to it. Second, most things fail open, or safe, which

preserves confidentiality and integrity, but not availability. Third, attacks on availability

can be both the result of a botched attempt at illicit access, or in some cases can be

the first move in such an attempt. Those seeking to gain illicit access are aware that

the time following a loss of availability in the form of a system outage can include

misconfigurations that provide opportunities for attacks, particularly if they control the

timing by initiating the service outage. If a rebooting firewall provides a momentary

vulnerability during its boot sequence, the attacker can exploit that momentary

vulnerability if they can initiate the timing of events with a service outage.

2.2 Authentication

While CIA – confidentiality, integrity, and availability – are acknowledged as the core principles of security,

two other characteristics have gained increasing recognition as important core principles. Authentication

(abbreviated AuthN) is the process of linking an authorized individual to an electronic identifier. For example, a

plastic badge (Figure 2) might have the name of a company and the name of a person, and serve to open the

door to the data center, but anybody could be carrying the badge. Customarily, the photograph of the badge

owner is also included on the badge, to serve as a simple form of authentication that the person holding the

badge is appropriately associated with the electronic ID carried by the badge.

Normally discussions of authentication begin with the user‐identifying index, or UserID. I wanted to

introduce the badge first both because it is a more concrete and tangible example of an authentication

Figure 2. Full Name




mechanism, and also to describe how the mechanisms that make for a good badge differ from those that make

for a good UserID. For this detailed discussion of the Authentication factors surrounding Badges and UserIDs,

see Appendix D. STAR Template

EISP STAR Template.xls

Appendix E. Badges and UserIDs.

2.2.1.1 Multi ‐ factor Authentication

UserID authentication – the process of ensuring that the person attempting to employ the UserID is

authentically the person to whom the UserID has been assigned – has traditionally been accomplished with a

password. When this is the only form of authentication required, it is called single‐factor authentication.

Enterprises

increasingly

consider

single‐

factor

authentication

insufficient,

in

some

cases

due

to

prudence

and

in

other cases prompted by regulatory requirements surrounding the handling of sensitive data.

Often another authentication element is introduced which in an attempt to employ a ‘second factor’ such

as requesting one’s “mother’s maiden name,” but this second element requires careful consideration. The

Federal Financial Institution Examinations Council (FFIEC) defines identity as being comprised of three factors,

or sets of authentication elements (Federal Financial Institutions Examination Council, 2005, p. 3):

1. Something the user knows ‐ e.g. a password, or personal identification number (PIN);

2. Something the user has – a digital identification card or a SecurID card;

3. Something the user is – a biometric characteristic, such as a finger or voice prints.

These factors are a password (something the user knows), a token (something the user has), and the

individual (something the user is). The more authentication factors one can confirm, the greater the chance of

positive authentication. In clarifying the intent of its 2005 notification to banks, the FFIEC stated in 2006, “By

definition true multifactor authentication requires the use of solutions from two or more of the three

categories of factors. Using multiple solutions from the same category ... would not constitute multifactor

authentication. (Federal Financial Institutions Examination Council, 2006, p. 6)”.

Thus when an enterprise asks for multiple “something you know” elements, such as asking for a password

and one’s mother’s maiden name, they are not actually using two‐factor authentication (2FA), and are not

appreciably increasing the security of the authentication solution.

In the case of Alice Anderson’s badge, two factors are present: the token (the badge) and the individual.

However if nobody inspects the badge to confirm that Alice is the person depicted on it, then the badge

functions as only single‐factor identification (1FA). The data center of a major bank in Minneapolis where I have

worked includes a guard who inspects each badge (however briefly) before it is swiped in the badge reader.




2.2.1.2 Levelsof Authentication

It is important, when discussing authentication, to keep in mind that different components of an enterprise

can

and

usually

do

have

separate

UserID’s,

and

separate

authentication

and

authorization

mechanisms.

2.2.2 Directory Services

The facility that responds to authentication requests is called a directory service or sometimes a name service. A number of directory service protocols have evolved along with the computer industry, including

X.500, LDAP, and Active Directory (AD). Domain Name Service (DNS) is the mechanism that translates website

names such as “www.google.com” into the digital address(es) of the server(s) that will respond to the request

(in this case 74.125.225.80 through 74.125.225.84). Similarly, directory services translate names such as

“Aanders01” into

a Windows

security

identifier

(SID)

or

the

equivalent

Unix

UserID

(UID).

Identity management (IdM) across a variety of new and legacy platforms and applications, as well as

badges and e‐mail addresses presents a considerable challenge to enterprise information security and

comprises a good portion of the overall security effort, because if the enterprise cannot tell who is who, it

cannot begin to appropriately authorize (AuthR) an individual’s access to enterprise resources.

2.2.3 Identity Management

A common

problem

for

large

or

growing

enterprises

is

that

of

users

having

to

remember

their

authentication requirements across multiple platforms and applications. For example, if an individual is unable

to remember their password this comprises an availability threat to the enterprise, because they will

presumably be unable to get their work done. However if individuals keep notes of their authentication

requirements, such as writing down their UserID and password, they create a confidentiality threat.

Several tools exist to assist with the considerable technical challenge of coordinating identities across all

the platforms and applications in an organization. The first coordinates all the authentication elements by

creating a single log‐on system (SLO). An individual in a SLO environment may use different UserIDs on

different platforms, but will use the same password everywhere and use a central tool to change that

password. This reduces the number of authentications elements that users must remember, reducing the

confidentiality threat of such information being written down.




There are a number of more or less secure methods for instituting SLO, but it is usually considered only a

partial or temporary solution to the problem of enterprise identity management because individuals are still

required to authenticate themselves on each platform and application, and the UserIDs are not centralized.

A more robust solution is Single Sign‐On (SSO) which synchronizes both UserID and password, and tracks a

single authentication event across multiple platforms and applications. In an SSO environment the individual

authenticates once – usually by logging in to their workstation – and then the SSO service handles all

subsequent authentication requests automatically by a variety of means. In some cases, the SSO system will

place tracking data such as an encrypted key or a security certificate generated on the workstation at login

time, in other cases it will intercept authentication requests and provide the necessary authentication

information, the exact architecture being vendor specific. One of the challenges to SSO implementation is that

every platform

and

application

has

to

be

made

“SSO

aware”

by

some

means

if

it

is

not

already

as

is

the

case

with some common‐off ‐the‐shelf (COTS) software.

The variety of authentication mechanism and SSO solutions has contributed to the development of an

interchange mechanism, the Security Assertion Markup Language (SAML), an XML based protocol which is part

of SOAP. SAML works to abstract elements of a security‐related communication, such as an authentication

request, in such a way that specific underlying security technologies and techniques are not mandated. Instead,

two “SAML‐aware” parties can conduct an authorization without needing to alter or be aware of their

underlying

security

infrastructure.

An

example

is

given

in

Figure

12

of

Appendix

F.

SAML

Request.

The ability to integrate and communicate between diverse application and platform authentication

technologies enables full‐fledged Identity Management tools for an enterprise. Implementing IdM provides a

number of benefits, chief among which are the use of a single authentication requirement for the enterprise.

This authentication can be single‐factor or multi‐factor. Additionally, UserIDs can be “normalized” across the

enterprise, meaning that diverse account names on different machines can be correlated to a single individual,

allowing for comprehensive management and termination of an individual’s UserIDs. Finally, IdM enables

enterprise‐wide role‐based authorization, described in the next section.

2.3 Authorization

Authorization (abbreviated AuthR in this book and most places, AuthZ in others) is the process of assigning

rights to an authenticated UserID. In an operating system this might involve: determining whether a given

UserID is allowed to run particular programs; whether a UserID can access, create, change, or delete particular

files; or whether or not the UserID is allowed to log in. In an application, authorization might determine which




forms a UserID can access, or which application functions are available. Typically UserIDs fall into one of three

broad categories: Privileged, Regular, and Non‐Privileged Users (Table 2.)

Table 2. General Classes of Authorization

User Category\Component

Operating

System

Application

Database

Privileged User Root (Unix)

Administrator (Windows)

Administrator Database Administrator

(can access multiple DBs)

Regular User UserID Functional User 1

: :

Functional User n

Database User 1

: :

Database User n

Non‐Privileged User Guest e.g. Demo User

or Web User

Unauthenticated Access

Privileged Users such as Administrators have the ability to create, edit, and delete user accounts, and are

usually able to access every available function of an operating system or application.

Regular User accounts usually fall into one or more categories of specific rights: operating system users

may have the rights to a particular application, while others have rights to several applications. Application

users may have rights to different sets of forms depending upon their job functions. Assigning and maintaining

the appropriate rights for a given individual comprises the bulk of the authorization challenge to the security

administrator.

Non‐Privileged or Guest accounts are vanishingly rare on operating systems due to the danger they pose if

a guest manages to elevate their access rights, but they are not unheard of. Application guest accounts are

fairly common, and include any service that does not require authentication, such as DNS, FTP guest accounts,

public web pages, etc.

Some of the concerns around authorization have to do with tracking the exercise of authorized rights as

well as detecting unauthorized access to elevated rights.

2.3.1 Discretionary AccessControl

Contemporary operating

systems

‐the

various

flavors

of

Windows,

and

Unix

in

its

Macintosh

and

multitudinous Linux incarnations – manage permissions using Discretionary Access Control (DAC), which allows

individual UserIDs to set their own access rights, within limits. Under DAC, Windows users can enable file

sharing, or set directories that they own to be readable by other users of the Windows system. Unix users can

make it possible for others to access one of their directories and put files into it, but not see any of the files in

the directory (the rarely used “‐wx” option for “can’t read, can Write, and can eXecute”.)




In these related operating systems2 a given UserID’s capabilities are augmented by its membership in

Groups. Groups are arbitrary collections of UserIDs with similar access requirements.

While this works in smaller environments, it does not scale well, with large numbers of users and

applications it can be extremely challenging to manage and track rights, particularly when groups are allowed

to include other groups – called “nesting groups – and particularly if an individual’s duties change regularly.

Even more daunting is the process of auditing permissions at any given time: if Alice leaves the company

suddenly, who knows which groups include her account? What assurance can be offered that all of Alice’s

accounts have been disabled?

2.3.2 Role‐based

Role‐based

access

control

(RBAC)

involves

assigning

rights

based

on

the

business

functions

one

fulfills

in

the enterprise – one’s “role.” For each role (and most individuals will have more than one role) rights are

assigned based on a template created for that role.

This is not terribly different from the de‐facto role based administration most enterprises undertake in

order to manage rights under DAC groups. In a DAC environment, if Bob is a new hire into Alice’s department,

and does the same job as Alice, the typical request for a new UserID for Bob would be “Create an account with

the same rights as Alice’s.” This make’s Alice’s account, for better or for worse, the role template from which

Bob’s is

created.

Role‐based access control differs from groups in that rights are intended to be assigned across multiple

platforms and applications, strictly based on the functional business requirements of the role (Ferraiolo &

Kuhn, 1995). For example, if Alice is in a DAC environment and discovers that she has a new need to access an

accounting program, she can ask to be added to the “Accounting” group. But what of poor Bob, or anyone else

whose rights were derived from those of Alice? They might not be added.

Table 3. Roles and Users

Role and Users Operating

System

Application A Database Accounting

Application

Role “App A Reports” No login

necessary

Reports only Read‐Only (R/O) Access

Only

None

Alice (Role App A Reports) None Reports Function

Application A Database

(DB) Read Only (R/O)

Add/Edit/Delete Function (Requested)

2 The file “C:\Windows\System32\drivers\etc\hosts” buried in the drivers directory betrays Windows’ kinship with the

UNIX “/etc/hosts” file. The files identically serve to override name resolution.




Bob (Role App A Reports) None Reports Function Application A DB R/O None

Role “Accounting Users” None None Read‐Write (R/W)

Access

Add/Edit/Delete

Function

Alice

(Role Accounting User)

None None Read‐Write Access Add/Edit/Delete

Under RBAC, Alice’s request for access to the Accounting program would not result in Alice being added to

a group, but in a re‐examination of the role in which Alice functions. If Alice and Bob’s function requires access

to the Accounting program it will be added to the role definition and everyone in that role will then have

access. If Alice is unique in her requirement, it might be the case that Alice is actually functioning in a different

role from Bob, and Alice would then have that role added to her profile (Table 3). So when Alice’s rights come

under review (such as when she leaves the company) one needn’t search every group for Alice’s UserID (or

another group

containing

Alice’s

UserID),

one

needs

merely

examine

Alice’s

UserID

for

the

enterprise

roles

she

fulfills (Table 4). RBAC allows system administrators to control access at a level of abstraction that is natural to

the way that enterprises typically conduct business.

Table 4. User Roles

User Role A Role B

Alice App A Reports Accounting User

Bob App A Reports

And periodic review of an individual’s functional roles, as part of an employee’s annual review for example,

can help eliminate the accumulation of obsolete rights that is so often the legacy of a DAC environment. Since

DAC permissions can be granted to a group on an ad hoc basis across several systems, it can be a nearly

impossible task to determine exactly where the group has been granted permission across an enterprise

(Tipton & Krause, 2006, pp. 21‐22).

2.3.2.1 Conflict of Interest

Because RBAC is built around functional roles, it can be additionally enhanced to prevent conflict of

interest in role assignment through separation of duties (SoD), a common principle that helps prevent fraud

and errors

by

ensuring

that

“no

individual

is

given

sufficient

authority

within

the

system

to

perpetrate

fraud

on

his own” (Sandhu, 1990). SoD ensures that if a person can approve or create a process, he or she is not allowed

to actually carry the process out individually, thus ensuring that at least two people are required to make a

change to a system.




2.4 Trust

An aphorism of the security practice is “trust, but verify,” a phrase that recognizes that at some point one

must

accept

risks

and

get

on

to

whatever

business

is

being

secured,

but

to

minimize

risks

(“verify”)

as

much

as

possible before so doing. The components of security architecture can be brought together to allow trust itself

to be transmitted… and verified.

2.4.1 Non‐Repudiation

A concept important to online banking is that of non‐repudiation, for a given communication, the claimed

identity of the sender is authentically that of the sender and this cannot be later disputed. For example, if Bob

conducts an online purchase from Alice, and Alice later calls with a collection problem, it needs to be

impossible for

Bob

to

claim

someone

else

conducted

the

online

transaction

–

otherwise

Alice

would

not

have

sufficient confidence in the system to create an online sales mechanism in the first place.

Digital signatures combine two of the concepts already reviewed: authentication and integrity. By first

authenticating a user’s identity and then sending that authenticated identity in a manner that guarantees the

integrity of the transmission, the recipient can be confident that the sender’s identity cannot be later

repudiated. Note that confidentiality is not part of this concept – the communication can be completely public,

and is in fact slightly riskier if it is kept secret since in that case both ends of the communication – Alice and Bob

– could

be

suborned

to

deny

the

transaction.

2.4.2 Digital Certificates

The only vulnerability left when establishing non‐repudiation is that the authentication mechanism on both

ends must be trusted by both parties. Alice has to trust that whatever mechanism Bob used to authenticate

himself is reliable. Digital Certificates combine confidentiality, integrity, and authentication to establish trust , a

means of assuring the authenticity of a complete communication. The key to digital certificates is the trusted third party, some entity that has established in advance the trusted identities of the two communicating

parties. This third party, the Certificate Authority or CA, distributes digital certificates in advance and over

some trusted method of communication, to Alice and Bob to guarantee their identities to each other in a their

communication. Digital certificates use asymmetric cryptography in order to provide confidential, non‐

repudiatable identification.

Asymmetric cryptography can best be explained by a simple metaphor. Asymmetric cryptography can be

considered a secure box with two locks. One lock is for putting messages into the box, and can be locked up




with a public key, so called because one can distribute public keys quite openly, on business cards or on one’s

website. A public key is a way of telling the world “if you want to send me something, put it in the secure box

and lock it with my public key.”

What makes asymmetric cryptography a‐symmetric is that the public key can only LOCK the box, it cannot

unlock it.

Unlocking the secure box requires the private key of the public‐private key pair created for this purpose.

The private key is kept secret and used to open the private box and retrieve the message. As we have already

learned, a digital signature can assure the private key holder that the message is authentic and has not been

altered. Additionally, the private key can be used to create a digital signature that can be confirmed by anyone

holding the public key – assuring the recipient that the private key was used to sign the message.

Asymmetric cryptography was invented during the 1970’s and revolutionized cryptography, a field with

nearly four thousand years of history. As notable as is the Digital Revolution, it’s arguable that the invention of

asymmetric cryptography is more important. Without it, many of the advantages of the Digital Revolution, such

as on‐line commerce and many forms of secure communication, would not have been possible, or at least been

practical to implement.

2.5 Review

We

have

reviewed

the

characteristics

of

Security:

Confidentiality,

Integrity,

Availability

(CIA)

and

Authentication (AuthN), Authorization (AuthR), non‐repudiation, digital signatures, and digital certificates. In so

doing we have explored some of the ramifications of each, from the distinction between Privacy and Secrecy to

Separation of Duties and Conflict of Interest and to the means for transmitting trust via digital certificates and

digital signatures. Now that we know what the parts are that constitute Security, we can define Security in a

manner that allows us to design a program to protect it within a given enterprise.

3 D e f en s e i n D e p t h

The key concept to “real” security is Defense in Depth (DID), borrowed from the military term for “elastic”

security, which simply put means having multiple layers of defense so that a single failure does not result in a

compromise of CIA, AuthN, or AuthR. Defense in Depth necessitates having multiple security controls in place

for People, Software, and Hardware. Software in this EISP extends across multiple portions of the network

architecture in order to provide resilience




3.1 Software

There are two categories of software to consider when managing the security of an IT environment:

software

developed

in‐

house,

and

common,

off

the

shelf

(COTS)

applications.

While

there

is

overlap,

each

has

its own security implications.

3.1.1 COTS Common off ‐the‐shelf applications can be divided into commercial, free, and open source applications.

3.1.1.1 Commercial Software

Commercial applications are typically the most readily accepted by management, even though commercial

software can

be

of

poor

quality.

Additionally,

commercial

software

carries

the

risk

of

licensing

and

copyright

issues. The Business Software Alliance (bsa.org) is a trade organization that works to counter illegal software

(software piracy), advertising anonymous reward programs for whistleblowers who report stolen software in

their workplace. So maintaining a careful software inventory and keeping software licenses up to date is strictly

necessary, both for legal compliance, as well as to reduce the risk of fines caused by disgruntled employee

whistleblowers.

Commercial software frequently comes with automated Internet‐based patching service from the

manufacturer, but

testing

patches

to

ensure

compatibility

with

one’s

installation

base

takes

time,

which

conflicts with patches that are issued in order to counter a newly discovered (or “zero day”) security

vulnerability.

3.1.1.2 Free Software

Free software can range from the most questionable, virus‐riddled freeware game to high quality software

cornerstones such as Mozilla Firefox web browser or IrfanView image processor. This makes it necessary to

handle software authorization on a case‐by‐case business necessity basis. Aside from the most proven or most

necessary free software, it is usually avoided. Additionally, some free software is only licensed for individual,

not commercial use.

3.1.1.3 Open‐ Source Software

Open source software is not actually a separate category, since it includes both free (FOSS) and commercial

(COSS) software. However open source software of either type share many common security considerations.




The security of open source software is premised upon Kerckhoffs’s Principle (Kerckhoffs, 1883), a 19th

century cryptography principle stating that the security of a system should not be compromised by being public

knowledge. This is a direct repudiation of the security fallacy of “security by obscurity,” meaning that one’s

security depends upon no one knowing how the system works. Since the first thing any attacker will do is learn

how the system works, Kerckhoffs’s Principle is considered more robust, and upon this principle advocates of

open source software claim it is intrinsically more secure than proprietary software.

One of the important claims in support of the security of open source software is that the program can be

analyzed for security by anyone using it. Detractors of this idea note that the attackers can also analyze the

programs, and that most users lack the time and the expertise necessary to conduct such analysis:

“Will people really review code in an open source project? All sorts of factors can reduce the

amount

of

review:

being

a

niche

or

rarely‐

used

product

(where

there

are

few

potential

reviewers),

having few developers, and use of a rarely‐used computer language (Wheeler, 2003)”

Despite these concerns, open source software is generally considered more secure, because it CAN be

reviewed, (whether or not it is) than closed‐source software which must be trusted without review.

3.1.2 In‐houseapplications

Software developed in house has the advantage of being free of licensing considerations. Unfortunately

software developed only for internal consumption only tends to have a greater number of security

vulnerabilities than

any

other

category

because

these

“utility”

programs

tend

to

be

developed

by

system

administrators and engineers outside of any SDLC process that might exist for the organization’s COTS

developers. Additionally such software tends to be written once and then forgotten: literally forgotten. The

author leaves the company or sufficient time passes that the author forgets, and now a piece of aging software

carrying out an important business function operates untended until it fails, all the while exposing any number

of undiagnosed security vulnerabilities.

3.2 Platforms

The platforms

–

the

combinations

of

server

hardware

and

operating

system

software

–

in

an

enterprise’s

data center present multiple vulnerabilities. If they fail there is a loss of Availability; if they are not maintained

with patches from the manufacturer, they present an increasing number of vulnerabilities of all types.

Authorized users of the operating system may deliberately or inadvertently violate their Authorized access.

Unauthorized individuals may gain access to the operating system. Any applications running on the platform




may offer the same set of vulnerabilities at the application level, as well as serving as a vector by which to

attack the platform itself.

Additionally, any other platforms, applications or databases accessed via any resources on one platform

become vulnerable if the security of that platform is breached. Due to their power and flexibility, each platform

presents a complete set of vulnerabilities found in the whole network, in microcosm.

3.3 Databases

Databases can for the sake of security be treated as a specialized form of application running on a

platform, albeit a particularly data‐rich application.

Databases can be secured by both UserIDs for account authorization, as well as encryption which may be

applied to

a database

as

a whole,

or

to

individual

columns

and

tables

within

the

database.

Of

particular

use

are

databases encrypted with different keys for different user roles or groups. This can help protect the

confidentiality and integrity of data even from database administrators (who, like system administrators, can

usually access everything).

For example, imagine an enterprise database that contains credit card numbers and employee information.

By encrypting credit card numbers with a key available only to authorized financial UserIDs, a database

administrator examining the database would see only the random collection of encrypted symbols. If personnel

information

is

encrypted

with

a

key

available

only

to

Human

Resources

personnel,

it

becomes

possible

for

database administrators to manage the database without having unauthorized access to the personnel records

of their colleagues.

The trick to this is that the keys for the decryption must be stored somewhere else than on the database

server or in the database itself.

The exact encryption options available when using a given database are extremely dependent on the

vendor, and may range from none at all to a full, versatile set of options, usually for an increasing price range.

The

business

drivers

requiring

a

database

must

be

balanced

against

applicable

laws

and

regulations,

and

weighed against cost and database capabilities when selecting what database to use for a given task.

3.4 Network

The word “network” has a multitude of meanings, even when narrowing the topic of discussion to security

architecture. If the term is taken to mean “all of the interconnected systems in the enterprise,” the number of

potential security vulnerabilities is extremely high. The enterprise network offers a full array of security




vulnerabilities when all the platforms and other devices such as printers and smartphones are included. From

taps on the wires and radio signals that comprise the most fundamental base layer of the network, up through

the routers and switches of the network layer, and up to the multitude of vulnerabilities of the application

layer, the more complex the system – in this case a network – the greater the risk of vulnerabilities.

If the network is considered only the interconnecting communications media between platforms and

databases the number of vulnerabilities drops considerably. At this level there are Authentication

vulnerabilities in the administration interfaces of the routers, switches, and other devices that comprise the

network infrastructure. Authentication vulnerabilities in such devices are often due to failure to change default

passwords set by the manufacturer, with vulnerabilities resulting from failure to apply manufacturer’s software

updates also common.

Otherwise vulnerabilities at the network level involve confidentiality threats due to data interception,

exposed keys allowing for encryption, or interceptions of communications via an unauthorized intermediary in

a communication chain – a “man in the middle” attack. Finally, attacks on Availability are common at the

network layer, including distributed denial‐of ‐service (DDOS) attacks, where a large number of computers are

programmed (usually with a distributed interconnected set of invasive programs called a “botnet”) to

simultaneously issue requests (often malformed for maximum impacts) that overload the recipient server. This

is a very common attack against websites, particularly by those seeking to make a political or social point

regarding

the

website’s

content.

Well‐configured firewalls reduce risk by limiting the traffic on a network to the minimum necessary in

order to conduct business. Frequently however firewall rules permit excess traffic, often due to the challenge

of disabling permitted protocols in a timely manner when the business purpose for the permission has lapsed.

Network traffic can be further reduced and controlled by implementations of virtual local area network or

VLAN traffic, a means of creating smaller, independent virtual networks that share common physical

infrastructure. And of course, the firmware on network devices such as routers and switches must be

maintained and patched. As with platforms, the best means of securing network devices is competent

management and maintenance to reduce the risk of incidents, and intrusion detection and response

procedures to handle any incidents that occur...

3.5 Assurance

Assurance is the practice of balancing the risks in all of the factors that have so far been reviewed.

Generally speaking, the best assurance that can be offered is when the risks are as low as possible. One way to




improve information assurance is to reduce risks by adding security controls around the various factors we

have already reviewed.

3.6

Research

methodologies

Methods of information analysis include the examination of internal and external patterns of events

recorded in logs; trends across time; and distributions of events across locations (space); associational trends

(correlation), and compound trends (aggregation) (Carnegie Mellon Software Engineering Institute, 2000).

These methods share similar challenges based on the quality of the data and its completeness, as well as

discerning valid data from background “noise.” Despite attempts to automate these processes, human

interpretation remains a key requirement in creating knowledge from data.

Where

the

Security

group

can

contribute

to

improvements

in

this

area

is

in

working

with

software

developers to establish clear circumstances that should trigger a security alert to be handled by monitoring

devices and personnel. Large enterprises may establish an incident response team, while smaller organizations

can route automated text alerts to on‐call pagers. Knowledge creation in the design phase – by determining

clear alert conditions and programming the applications to trigger alerts – results in more effective incident

management than does attempting to interpret security incidents from a mass of uncoordinated automatic log

output.

3.7 Knowledgecreation

Repeatedly throughout this analysis we’ve seen where knowledge must be created for the EISP to be

successful. Data collected in application and server logs, trouble ticket trends, incident reports, penetration

test results and other raw data must be analyzed in order to derive information that can be used to evaluate

progress and plan for the future – in other words, knowledge.

Devices such as Host‐based Intrusion Detection Systems (HIDS), Network‐based Intrusion Detection

Systems (NIDS), offer automated attempts to distinguish security incidents from the flood of log information,

transforming raw data into knowledge.

Traditional methods of analysis include cost/benefit analysis, which is sometimes all that a smaller

enterprise can accomplish with limited resources. Traditional cost/benefit analysis is of limited utility. “Security

improvement projects are very human‐effort intensive [and] their… costs are often seen as ‘hidden costs’ that

many companies traditionally have difficulties in quantifying.” (Xie, 2004).




For mid‐ and large‐size enterprises, a number of risk‐analysis frameworks such as FAIR (Jones, 2005), P2I2

(Hall E. , 1998), and the NIST 800‐30 Risk Management framework (Stoneburner, Goguen, & Feringa, 2002)

exist to calculate threats, vulnerabilities, probable loss magnitudes, and loss event frequencies. All work in a

manner similar to traditional risk analysis practiced by the insurance industry, but information security risk

analysis is hampered by the difficulties setting a value for the data assets to be protected, difficulties setting a

cost for any given security incident, and lack of accurate incident detection and reporting.

The basic risk equation is simply Risk=Probability x Cost (Hall E. , 1998, p. 92). The tricky part is assessing

these values accurately. What, for example, is the actual percentage chance of an unauthorized access to a

particular datum over a particular year for a given enterprise? What are the actual costs of a security breach?

Inevitably the numbers inserted into this equation are going to be inaccurate, and the various risk assessment

frameworks under

study

today

each

seek

in

their

own

way

to

improve

the

accuracy

of

the

results,

sometimes

for a particular industry, and sometimes in a general sense.

For example, credit card data can be valued at $10 per card number (Bilton, 2011), so if we postulate an

enterprise storing 100,000 credit card numbers in a database, the value of that database can be estimated at

$1 million. This is the reward motivating the attackers.

Let’s say there is a one‐in‐five chance of hackers gaining unauthorized access to the database in any given

year, but that a new $200,000/year security program can cut that risk in half, to one in ten. Is the cost of the

program worth

the

benefits,

where

the

benefits

are

reduced

risk

of

an

incident?

The cost of an incident to the enterprise includes the cost of the infrastructure to detect the incident, to

notify all interested parties as required by law, the cost of evaluating the losses, and the cost in lost business

which averages $188 per record in the United States (Ponemon, 2010). The cost of the security program is

given as $200,000/year.

We then have these two equations:

Risk of inaction = Threat of .02 x Cost per record of $188 x 100,000= $377,000.

But if we purchase the $200,000/year security program, these numbers become:

Risk with new program = Threat of .01 x Cost per record of x $188 = $188,000.

The numbers are, as mentioned, extremely “fuzzy,” but they can help with planning: spending $200K per

year on security saves $188,000 in risk per year, a near break‐even for this very simple case. Additionally,

according to the statistics of binomial probability, over ten years there is about a 62% cumulative chance of the




a security incident in the unprotected case where the odds are 2‐in‐10 of success, but only a 26% chance of a

security incident across the same period if the chances of a security incident are reduced to 1 in 10. So the

chances are better than even that the unprotected network will experience a security incident in the next ten

years, but it is fairly unlikely that the protected network will suffer a security incident over the same ten year

period.

Again, these are the broadest of risk assessment estimates, provided to illustrate the process. In practice

an enterprise will need to research and select a risk‐analysis framework best suited to its operations, and

conduct a thorough evaluation of the costs and benefits to be expected in that particular case.

4 St r a t e g i c El em e n t s o f a n EI SP

So we’ve met the characters – Confidentiality, Integrity, Availability, Authentication and Authorization –

and we’ve learned they are set in a complicated plot of often‐conflicting motivations – business, financial, legal,

regulatory, and operational. And we’ve explored the setting, the physical environment of platforms, network

infrastructure, and applications within which the business of the enterprise is carried out. The plot of this

performance, which we shall call “The Enterprise Information Security Program,” (EISP) is the success of the

enterprise, whether success is measured in profits or graduating students or improved health and well‐being

among a population or in something else entirely.

The Enterprise

Information

Security

Program

is

comprised

of

several

parts,

including

leadership,

standards,

policies, processes, techniques and training. The program must be coherently written so that it can be

explained in a manner that gains general acceptance, and it must be compelling enough to facilitate leadership.

4.1 Organizational Structureand Reporting

This book presents the most basic components of an EISP, from the point of view of a security executive

such as a CISO. Yet some professionals do not hold with this analysis. In discussion with Ben Tomhave, former

Technical Security Director at Highwinds Network Group, it was clear he does not believe that a strategic

security role

is

viable

in

today’s

business

environment.

“I’m biased because I have worked in the field and I haven’t found success in the role, but lately I

get the feeling that the role of the CISO is on the way out. The security industry overhypes risks and

charges too much for mitigation, and its driving security out to managed security providers and the

cloud. (Tomhave, 2011)”

Others, such as Motorola CISO William Boni, believe that the position of Chief Risk Officer will replace the

CISO, focusing on risk assessment and less on technology,




“As the role develops, the CSO will become more of a chief risk officer, an executive in charge of

the business risks married to security concerns. Most of the skills will have little to do with

technology. (Boni, 2011)”

Part of the reason for this skepticism, I believe, is due to the perceived slowness with which the CISO role

has been integrated into the business landscape. Security professionals seeking to advance their careers might

be frustrated by the shortage of available C‐level security roles at major businesses. Others may be observing

the challenges faced by those who manage to achieve the CISO role. Both of these observations are valid, but

they miss a couple of fundamental points.

First, the CISO it is my observation that the CISO is mis‐positioned in the enterprise. In most organizations,

the CISO reports to the Chief Information Officer, or the Vice President of IT (Oltsik, 2011). This constitutes a

dangerous conflict of interest (Whitmer, 2006). The role of the CIO, or the VP of IT, is to keep the network running. This is adversarial to the function of the CISO, who seeks to keep the network running securely . By

having the CISO report to these operational positions, the CISO risks being overridden whenever the need for

security comes into conflict with the mission of those roles to keep the data flowing.

While working for a major Twin Cities based retailer, I was involved in the successful effort to implement an

EISP – over significant political resistance. What facilitated this success was the shift in reporting of the security

group, from under the VP of IT to the Chief Financial Officer. This structure makes sense from a number of

aspects.

First, the CISO role is, as mentioned, adversarial with that of the CIO or VP of IT. The CISO issues security

requirements that the CIO must meet, and when the CISO reports to the CFO the CISO can leverage the power

of the purse to compel cooperation.

Second, the CFO is responsible for the financial health of the enterprise – and the CISO conducts risk

analyses that the CFO can employ in making budget decisions.

In my research (which was extensive) I found no formal advocacy for this reporting structure, although I did

find anecdotal mention of its feasibility in discussion forums and blog posts (Umerley, 2011).

I believe the growing skepticism regarding the viability of the CISO role is due to the conflict of interest in

the way this role is most commonly structured. Rather than inventing a new “Chief Risk Officer” role, the case

should be made for the CISO reporting to the CFO.




4.2 Principles

Since Security is comprised of CIA plus AuthN and AuthR, it’s obvious these elements will factor into

Enterprise

Security.

Other

factors

that

come

into

play

are

those

which

drive

the

enterprise

itself.

If

an

enterprise is a standard for‐profit business then the need to generate a profit and to satisfy the shareholders

will always exist. Whether for‐profit or non‐profit, finances will always be a factor. If the enterprise falls under

any regulatory umbrellas, then the need to comply with regulations will be a factor, and of course legal

compliance is necessary for any enterprise.

Enterprise Security requires balancing all of these and many other factors in order to come up with an

optimally secure solution that facilitates the goals of the enterprise. For example, if a for‐profit business

decides it needs a firewall, its financial drivers will urge the least expensive firewall available, while functional

requirements may call for a high‐availability (HA) firewall cluster, and regulatory compliance may insist that

Network Intrusion Detection (NID) be part of the solution… by which time the financial considerations may

have reached a critical level of concern.

Balancing all of the business, regulatory, legal, functional, and security factors in search of an optimal

solution is a process called Risk Management. The key to Enterprise Security, Risk Management requires

balancing the security vulnerabilities inherent with doing business against the rewards of success. The

beginning step is Risk Assessment (RA), a discovery process of identifying sources of risk and evaluating their

potential effects.

It

is

normal

to

start

the

risk

management

process

with

fuzzy

issues,

concerns,

doubts

and

unknowns. The process of risk management transforms this uncertainty into acceptable risk. (Hall E. , 1998, p.

5) And “acceptable risk” is one side of the risk/reward structure that underlies modern business.

4.3 Project Charter

The first thing required when implementing an EISP is a charter outlining the goals, principles, and

authorization to carry out the effort. A project charter is an important document to keep this lengthy

undertaking from drifting off course, and serves to justify the project to skeptics. An example charter is

included as

Appendix

A.

EISP

Project

Charter.

4.4 EnterpriseLeadership

The backing of senior management is of critical importance to the long‐term success of an Enterprise

Information Security Program. While it is possible for managers and employees to effect organizational change

from the bottom up




An EISP is initiated when an organization’s Board of Directors or Chief Officers make the strategic decision

to appropriately secure the organization’s sensitive information. The EISP is designed by security personnel in

consultation with other departments that might be available, such as legal counsel, human resources,

regulatory compliance and of course information technology (IT). The EISP is referenced by managers to

develop the implementation projects to meet the strategic goals of the organization’s leaders. Examples

include decisions regarding the type of computer equipment to purchase based on security requirements,

whether to develop security training courses in house or pay for professional instruction, new security skill

requirements for hiring new employees, and implementing secure programming practices for software

development. The completed EISP describes the operational requirements and procedures necessary to

implement its programs. Examples include new firewall configuration requirements and updated disaster‐

recovery

procedures.

For our hypothetical example of building an EISP from scratch, we’re going to assume a small medical

service company that’s expanding into producing a medical product. A growing organization is both exposed to

new security regulations while also reviewing how to manage resources while expanding, including security

resources.

4.5 BusinessLeadership

As with other elements of cultural change, the business leadership approach to each enterprise must be

specific to

the

enterprise

culture

and

the

specific

circumstance.

Business

leadership

must

be

‘customized’

to

every enterprise. In the politically‐charged culture of the prior example, a bottom‐up approach was not able to

overcome entrenched power blocks. Instead, a top‐down ‘comply or die’ structure that demanded compliance

if projects were to move forward was much more successful. Decentralized enterprises that encourage

individual initiative would strenuously object to such a heavy‐handed, centralized approach.

And just as it’s of critical importance to know your enterprise in order to customize your approach to EISP,

it is important to know your own style of leadership. As an advocate of the changes necessary to implement

the EISP,

you

will

need

to

exhibit

leadership.

In

order

to

be

effective

and

produce

enduring

change,

it

is

critically important to understand your own style of leadership, and anticipate how that style will be received

by the enterprise. Personality dimensions contributing to one’s leadership style include one’s place on the

spectra of extroversion and introversion, agreeableness and irritableness, conscientiousness and

impulsiveness, emotional stability, and openness to change (Burke, 2002, p. 125). These characteristics can in

turn help you assess the kind of leader you may be – authoritarian, democratic, transactional,




transformational, servant‐leader, etc. There is no shortage of literature regarding assessing and developing

your leadership style, from Lewin’s fundamental works (Lewin, 1944) to contemporary business self ‐help books

available at any major bookstore or library.

When you understand the culture of your enterprise, the characteristics necessary for the EISP, and your

own style of leadership, you’re ready to begin the process of introducing the EISP into your enterprise. You’ll

want Strategic level endorsement from the CEO or Board in your Project Charter (see Appendix A. EISP Project

Charter), and you’ll want to be able to offer a service framework to assist operational personnel with the

details of the kinds of services the security group can offer to assist with making the necessary changes.

Your EISP needs to introduce security changes that will comply with all laws and regulations to which your

enterprise is subject while allowing your enterprise to conduct operations. It needs to be introduced in a

manner that leverages available authorization, whether one has full backing of the Board and CEO, or must

struggle from an operational level to implement changes at higher levels of management. To implement the

EISP, you will need to exercise leadership by communicating the need for security improvements. And once the

EISP has been implemented, the enterprise will require training and awareness programs in order to keep

employees up to date on changing enterprise security requirements.

4.6 Businessdrivers

Business drivers will be unique to each enterprise, which could be anything from a non‐profit healthcare

institution to an international Fortune 500 corporation to a small home‐based business to a neighborhood

volunteer organization. Simple profit motive is a strong driver for profit‐based businesses, but financial

concerns exist in every enterprise. Other drivers include keeping stockholders (if any) satisfied, which can

sometimes (but not often) diverge from simple profit motive (e.g. if a CEO embarrasses their company,

replacing the CEO might override profit concerns). In a non‐profit enterprise, the mission will drive the

enterprise.

In every case, the key business driver to keep in mind is that the enterprise must thrive if its security is to

have any

relevance

at

all.

For

example,

the

best

way

to

keep

hackers

from

breaking

into

your

network

might

be

to disconnect your company from the Internet completely, but this security solution would work poorly for

online sales giant Amazon.com.




The aphorism I have developed regarding security’s role in an enterprise is “the job of security is to put

down guardrails, not roadblocks.” Guardrails help guide and protect traffic moving at an optimal speed for

driving conditions. Roadblocks impede the “mission” of a road, and frequently compel drivers to find riskier or

more inefficient routes around the roadblock. In any enterprise, if security creates roadblocks to the primary

business drivers of the enterprise, security will be bypassed or eliminated.

In discussing the reporting structure of the CISO it was noted that the CISO reporting to the CISO or VP of IT

constitutes a conflict of interest. In part this is because these roles inevitably will see the CISO as a roadblock –

for example, any time that expedience suggests leaving the road of best practice, those guardrails WILL seem

like roadblocks. It must be kept in mind at all times that the role of the EISP is to facilitate the goals of the

enterprise. Abusing the role of the EISP through excessive proscription will doom it to failure.

4.6.1 Organizational Change

The process of creating an enterprise information

security program is, as ought to by now be clear,

technically extremely complex. Enterprise drivers must

be coordinated with domestic and even international

laws, regulations,

and

industry

best

practices

in

a

fashion that allows the enterprise to thrive.

Requirements that satisfy these laws and regulations must be built and standard architectures and services

assembled that meet these requirements. Risks must be assessed and priorities established with an eye

towards the resources available and long‐range enterprise goals. Programs and hardware must be written and

configured in order to meet these requirements and standards while also providing real security.

And that is the easy part.

That’s the

easy

part

because

machines

do

what

one

tells

them

to

do,

and

making

plans

is

much

easier

than

carrying them out, while making changes that involve people are extremely difficult. Almost regardless of size,

enterprise cultures, once established, are difficult to change. Indeed, authors such as Gladwell argue that

regardless of the size of an enterprise, its effective internal group sizes are no large than 150 people. Larger

groups, Gladwell claims, will either spontaneously subdivide into smaller groups, or remain large and




ineffective (Gladwell, 2000, p. 182). The point being, all organizational change ends up being change to small

units, and despite this organizational change remains the hardest part of implementing an EISP.

Organizational change can be conducted using a number of strategies – evolutionary or revolutionary,

individual, group, or system levels ‐ using a number of change frameworks for understanding and transforming

enterprises such as Porras, Weisbord, Nadler‐Tushman and Burke‐Litwin (Burke, 2002). These models work to

score and prioritize enterprise elements such as the external environment, mission and strategy, management

practices, individual and enterprise performance measures, individual needs and values, and motivation,

among others. Scoring these organizational components suggests where effective change can most readily be

targeted – if employee needs and values are not being met, employees will be receptive to changes that

address their needs and values. If one is implementing security changes, and if these can serve to align

employee values

with

enterprise

goals,

the

changes

may

be

more

readily

adopted.

When implementing enterprise changes, elements to consider include the enterprise culture, or

personality; the way that changes will impact power and enterprise politics; the structure of the enterprise and

how business silos network or communicate; incentives and intrinsic rewards to offer employees, and how

training will be developed and delivered. Increasing security awareness in an enterprise will always disrupt the

enterprise, because security and operations have different objectives. The goal of operations is to meet

business objectives in the most cost‐efficient manner possible; the goal of security is to meet business

objectives

in

a

secure

and

legal

fashion,

with

cost

and

even

operations

secondary

to

compliance.

In

short,

operations asks “How can we do this BEST?” and security asks “How can we do this RIGHT?” Conflict is

inevitable, and this challenge to the core mission of the enterprise is why senior management support is

important to overall success.

4.6.1.1 Exampleof Cultural ChangeinEISP Implementation

For example, when I worked for a major Twin Cities‐based retail company, my security team was tasked

with implementing security changes to comply with Payment Card Industry (PCI) standards – from the bottom

up. While

mandated

by

the

Board,

there

was

no

strategic

level

support

for

the

program.

In

fact

the

CEO

was

quoted at the time as saying that the retailer was not interested in IT, it was in the business of “selling socks.”

Due to poor management, the leader of the PCI compliance team (my direct superior) was reporting to over a

dozen senior managers every week. Each was critically concerned with the power and politics of how these

changes would impact their operations.




Meanwhile the organization was experiencing “compliance exhaustion” following several years of changes

necessitated by the passage of the Sarbanes‐Oxley Act (SOX), legislation primarily focused on changing to

banking rules including information security changes. So large is this organization that the internal culture

adopted a very arrogant posture. “We’re the [nth]‐largest retailer in the world,” one manager baldly stated,

“why should we let outsiders tell us how to run our business?” That the “outsiders” in the case of SOX were the

Congress of the United States did not impress this manager. With no top level support, managers in various

business silos began “dragging their feet:” missing deadlines and failing to attend meetings without

explanation, and complaining to their superiors of the burden the PCI changes placed upon their operations.

These three problems – lack of senior management support, compliance exhaustion, and resistance to

outside authority ‐ were addressed by changes to strategy, structure, and culture, respectively. First, our group

addressed the

Chief

Financial

Officer

in

order

to

make

him

aware

of

the

financial

costs

to

the

enterprise

of

failure to meet PCI compliance deadlines. Since there was a chance that the PCI Council could revoke the

enterprise’s merchant privileges, the risk costs were in the tens of millions of dollars in the short term (1‐3

months) and in the hundreds of millions of dollars in the mid‐term (6‐12 months). We successfully convinced

the CFO to remove the PCI compliance group from under the Information Technology department (where

security is in a conflict of interest with the operational goals of the department head) and place it under his

control in the finance department. This removed the conflict of interest, and placed the security group in an

appropriately adversarial role with the IT department. This ‘adversarial’ relationship is not negative: security

should be continually challenging IT to become more secure for the good of the enterprise, while IT continues

to meet its operational goals.

An additional benefit to this change was that the security group now had the power of the purse. Lines of

business (LOBs) seeking to undertake projects had to meet security requirements before receiving funding.

Suddenly ‘compliance exhaustion’ disappeared.

Finally, the provincial arrogance that resented “outsiders” influencing operations was addressed by the

creation of high‐water mark security requirements that met all external laws and regulations. These were

labeled “Enterprise Requirements,” and reference to external requirements and laws was discouraged. Security

requirements were no longer seen as being imposed from the outside.

As a result of all these changes, the project was eventually successfully implemented, only slightly behind

schedule.




This example describes how considerations of strategy, structure, and culture were addressed to bring a

security project to a successful conclusion. The corporate strategy that lacked senior level support was

addressed by an individual appeal to the CFO. The result was a change in structure that removed the PCI

compliance group from a conflicting position under the CIO and empowered the PCI group to withhold funding

to non‐compliant projects. And an arrogant culture was appeased by creating “internal” requirements, a step

which also proved more efficient for compliance purposes than attempting to address laws and regulations in a

round‐robin fashion.

4.7 Maturity

In order to track the organization’s own functional capabilities – including but not limited to security

considerations – we’ll use the Capability Maturity Model (CMMI) developed by the CMMI working group of

businesses and academics at the federally‐funded Software Engineering Group at Carnegie Mellon University.

The first step in planning any program with broad impact on the enterprise is to assess the capabilities of the

enterprise, and the CMMI facilitates this by categorizing any organization into one of five stages:

1. Processes are unpredictable, poorly controlled, and reactive. “You can’t do the same thing twice and get the

same result.”

2. Processes are characterized for projects and the enterprise is often reactive. Accomplishing individual projects

does not lead to lessons learned or contribute to enterprise process improvement.

3. Processes are characterized for the overall enterprise and are proactive. Projects build processes based on

enterprise standards.

4. Processes are measured and controlled. Knowledge is generated that contributes to consistency and quality

improvement.

5. The enterprise has enough overall structure that it can focus on process improvement.

For the sake of our example, we’re going to start our enterprise at CMM level 1 – the enterprise cannot

execute the same process twice and get the same result. For example, if one new employee arrives for work on

Monday, their workstation might not be ready for use until the end of the day. If another new employee

arrives for work on Thursday their workstation might not be ready for use until the following Monday. These

differences might be due to resource availability (“The guy who sets up accounts is out for the rest of the

week”) or communications breakdown (“The service desk overlooked your request until late Friday”) or

whatever reason

–

the

enterprise

isn’t

capable

of

reliably

delivering

services.

Assessing where your enterprise operates along the scale of the maturity model will help a strategic

decision‐maker determine

5 T a ct i c a l El em e n t s o f a n EI SP




5.1 Information Security Standards

Information security standards are established by an enterprise as rules guiding the management of

individual

aspects

of

business

information

processing.

There

are

a

number

of

third

party

organizations,

including the International Standards Organization (ISO) that provide template information security standards

frameworks such as ISO 27002 which a particular enterprise can and should customize to suit the business

goals of the enterprise. The ISO 27002 framework is comprised of twelve chapters:

1. Risk assessment and treatment

2. Security policy

3. Organization of information security

4. Asset management

5. Human resources security

6. Physical and environmental security

7.

Communication

and

operations

management

8. Access control

9. Information system acquisition, development, and maintenance

10. Information security incident management

11. Business continuity management

12. Compliance

When completed, the enterprise information security standards should represent the “high water mark” of

requirements such as password length (Figure 3) where we are pretending that HRSA, NIST and HIPAA have 7, 6

and 8 letter password length requirements. By requiring 8 characters, the enterprise would meet or exceed all

requirements. High water mark standards must cover all industry best practices, industry standards, and

standards imposed

by

law

and

regulation

(Figure

4)

as

well

as

anywhere

the

enterprise

has

decided

for

its

own

reasons to exceed external requirements.

Figure 3. High Water Mark Password




Figure 4. Multiple Requirements

Standards include such elements as minimum required password complexity, server operating system and

memory requirements, and lead times required for change control reviews. The eventual enterprise security

standards would encompass the high water mark requirements of all applicable laws and regulations, as well as

any enterprise standards (white box in Figure 5) which the enterprise cares to impose for its own purposes.

Figure 5. High Water Mark Standards

A comprehensive set of security standards is a tactical document that translates the strategic security goal

of the enterprise into a set of instructions for managers to use in designing operational security controls.

5.1.1 Regulatory Requirements

Regulations are a hybrid between law and industry and security is concerned primarily by two types,

governmental and

self

‐regulation.

Recognizing

that

only

particular

industries

have

sufficient

expertise

to

design

rules for industry, governments empowered regulatory agencies that can set specialized governmental

regulations for industry which carry the force of law. And industries will develop and enforce their own

regulations that do not carry the force of law, usually in order to avoid the often‐heavier burden of

governmental regulations.




Among many examples of governmental regulations are such well‐known examples as the Health

Information Portability and Accountability Act (HIPAA), the Federal Information Security Management Act

(FISMA), and the Family Educational Rights and Privacy Act (FERPA).

Industrial self ‐regulation includes standards of the North American Electric Reliability Corporation (NERC),

an organization of United States electrical grid operators, and the standards of the Payment Card Industry (PCI)

Security Standards Council, founded by American Express, Discover Financial Services, JCB International,

MasterCard Worldwide, and Visa Inc. in 2006 to oversee the handling of credit card information by merchant

organizations.

Governmental regulations must be observed as laws. This can be quite challenging, as so many

governmental regulations exist that is it increasingly difficult to assure that all of them have been taken into

consideration when designing solutions. However the government does not have the resources nor the

inclination to prosecute enterprises for any but the most egregious and/or persistent of legal infractions, and

to some extent well‐documented due diligence will shelter an enterprise from immediate legal sanctions in

cases of strict liability. If an enterprise can prove beyond a reasonable doubt that it has done everything

possible to comply with the law as it understood it with the aid of legal counsel, the government’s interest is

usually in seeing the matter rectified rather than pursuing a conviction.

Industrial self ‐regulation is similarly interested in working to resolve problems with compliance before

beginning to

bring

penalties.

The

fact

that

industrial

regulations

do

not

carry

the

force

of

law

has

both

good

and bad aspects. While the threat of legal action is powerful, it also sets in motion the court system, which has

its own implacable set of processes. Industrial self ‐regulation is therefore more direct, even if it lacks the force

of law.

For example, the PCI Data Security Standards3 provide a comprehensive set of requirements for how

customer information must be handled my merchant enterprises that wish to process payment cards – credit

and debit cards. Platforms that handle PCI information must be isolated in their own network security zone.

Fines

for

noncompliance

can

be

substantial,

up

to

$25,000

per

month

for

failure

to

comply

with

DSS

(Harwood,

2011, p. 250). Such fines have rarely been leveled, but they have occurred. In 2007 the TJMaxx Corporation

suffered the exposure of 9.6 million credit cards numbers (Zetter, 2010) after failing to comply with PCI DSS

requirements and suffering one of the largest security breaches ever, and was subject to a $40.9 million

penalty (Brooks, 2010).

3 https://www.pcisecuritystandards.org/security_standards/




More commonly, vendors that fail to comply can lose the ability to process credit cards by being placed on

the PCI “MATCH” list. This threat is more immediate and direct, as many commercial enterprises could not

continue to exist without credit card transactions. Qualified Security Assessors (QSAs) ‐ auditors who have

passed the PCI auditing certification process ‐ are much more interested in working with an enterprise to

resolve noncompliance concerns than in levying fines or removing merchant processing ability.

For example, I worked with a retailer who proudly installed a new security camera system in all of their

retail stores. The new cameras produced sharp color recordings, and could be remotely aimed and zoomed to

capture clear images of suspects. Unfortunately, the cameras were SO good that it was possible to zoom in on

a customer’s credit card and read the card number, security code, and cardholder’s signature. The retailer had

inadvertently made the security camera network subject to the PCI DSS security compliance requirements.

Not only would actually putting the camera network into the secure PCI zone have been prohibitively

expensive, but it would have so overstretched the architecture of the PCI zone that the zone’s security would

have been called into question. The QSA auditor did not, however, resort to threats and fines. A waiver was

issued allowing the merchant to come up with a solution. Six months later when the QSA returned, a solution

had been found: the expensive high‐quality cameras would be outfitted with plastic collars that limited their

ability to zoom and pan so that credit card information could no longer be recorded. The QSA accepted this

solution and the problem was resolved.

The process

the

QSA

followed

in

handling

this

situation

was

an

example

of

Risk

Management.

A

temporary

waiver was judged an acceptable risk, and the collar solution was judged an acceptable long term solution.

Certainly risks remain. A collar could be removed or be accidentally dislodged, restoring the camera’s zoom

ability. A customer could deliberately expose a credit card to the camera. But the auditor’s Risk Assessment

evaluated these risks as acceptable within the overall environment of the merchant enterprise.

5.1.2 Equipment Standards

As with any complex problem, one way to address it is to break it down into a series of smaller problems, in

this case by making some decisions in advance. For example, if the question is “How to best secure all

enterprise workstations,” the question can be simplified by securing a single workstation, then repeating that

process through the development of a “standard platform image” that is copied to create subsequent

workstations that have a known and approved security profile. The decision to secure workstations in this way

is a policy, and the prototype platform one develops becomes a standard.




By adopting proven information security standards for platforms such as employee workstations and

enterprise workstations one also creates a “security baseline,” a complete set of predetermined configuration

settings for account policies, user rights, log settings, system services, and file permissions, etc. The risks

inherent in these settings are considered to be “accepted” by the enterprise as part of the cost of doing

business. Any increase in these baseline risks caused by changes to the platform such as adding software or

services need to be justified against the benefit these changes bring to the enterprise. This process of analysis

and risk acceptance is at the heart of the risk management section.

5.1.3 Technology Managing technology would probably still be challenging were the technological environment static, but in

fact we

are

still

riding

the

rapid

swell

of

IT

capabilities,

so

managing

technology

is

a tremendously

complex

matter. Servers that were cutting edge only a few years ago become quickly obsolete. Platforms don’t merely

change to become faster; they become virtual platforms and then virtual platforms hosted in “the cloud,” the

array of leased services available over the Internet. Mission critical servers multiply into server arrays and

become distributed over multiple data centers.

The key to managing the technology is to simplify it through the establishment of architectures, standards,

and criteria for product acquisition, with a robust set of management practices to keep the technology up to

date.

5.2 Information Security Processes

Information Security Processes are documented business processes implemented or monitored by the

security team in order to reduce the risk of information security incidents and/or comply with law, regulations

or enterprise standards.

For example, the allocation appropriate rights and resources to a new UserID and providing appropriate

information to the UserID owner in order for them to use the account – a process typically referred to as

“provisioning” –

is

an

information

security

process.

If an enterprise is regulated then it is important that processes are documented and tracked, and that

penalties are imposed and corrections made if information security processes are not followed correctly. This

documentation allows for audit preparation and review, and serves as a source of knowledge for the enterprise

to monitor its security compliance.




5.2.1 ProcessInsertion

Three extremely basic enterprise processes need to exist in order to begin employing the STAR documents.

First,

a

change

control

process

needs

to

be

available.

If

an

enterprise

lacks

a

formal

change

control

process,

there is still a de facto process that involves talking to key personnel such as system and database owners in

order to make changes. Whether formal or de facto, the first step is to get the STAR document inserted as a

requirement in the change control process.

Second, some form of architecture review needs to exist. Again, if no formal “architecture review board”

exists, there will still be a de facto review process that “sanity checks” ideas for feasibility.

Finally, if the enterprise develops software then a software development lifecycle (SDLC) needs to be

formalized. Again,

even

if a formal

SDLC

does

not

exist,

an

informal

system

will

exist

that

can

be

documented

and formalized.

These are all basic operations that any organization will need to formalize before moving out of CMMI

stage 1, and they are essential to facilitating the implementation of basic security metrics such as those

captured by STAR.

5.2.1.1 ChangeControl

Change control processes end with an approval process, at which point the enterprise accepts the risk

inherent in the change. Without risk analysis, these risks are accepted blindly or intuitively. The Change

Template includes a scoring mechanism hidden from the casual user (to discourage users from gaming their

answers to produce lower scores). These scores are arbitrary but can be gathered over time in order to build

trends of relative risk as part of an overall risk assessment process.

The first step to beginning to gather security metrics is to make completion of the most basic STAR

information a requirement for gaining change control approval. Each project seeking to implement a change

could then be asked to fill out the STAR Dashboard, Data Classification, and a copy of the Change Template.

This will

allow

the

enterprise

to

begin

identifying

the

owners

of

various

enterprise

components,

the

sensitive

data handled by those components, and to begin assembling a base of information regarding the risk of various

changes.




5.2.1.2 ArchitectureReview Council

In any organization there is some group, here termed the Architecture Review Council (ARC), which

coordinates

the

management

of

different

sectors

of

the

data

environment

–

coordinating

servers,

database

resources, external and external websites, etc. – with the overall IT roadmap and operational plans. Whether

or not the ARC is a formal group with formal processes or an ad hoc collection of data center administrators,

the group is responsible for overseeing the IT implementation of new projects. This is the group that must be

persuaded to add STAR documentation to their approval requirements.

In addition to the Dashboard and Data Classification, the Security Plan tab collects the basic description of

an application or infrastructural element sufficient to provide an overall idea of the network architecture and

data flows involved. For slightly more mature operations, a network diagram including data flows and data

stores may be part of the ARC approval process (Figure 6.) To these the STAR document adds the Risk Review

Template, which can be copied for each stage of the element’s evolution within network environment.

Figure 6. Example Security Data Flow Diagram

The Risk Review identifies each data store, data flow, data processing step, and interaction with other

enterprise elements or boundary transition from one security zone to another. Each of these can be marked as

new, inherited, accepted or unaccepted risk, or a risk area removed from one version to the next, and these

are scored to provide an arbitrary relative risk rating.




# Type Sensitive

Data

Risk Score Description

1 Border PHI New 1 Encrypted e‐mail, controls based on e‐mail encryption solution

Ports 465,

585,

993,

995,

rules

10179,

10181,

12113

12114

on

FW

2 Border None New 0 No sensitive data, but if order requests or case activities are

deleted or missed, would the process catch this?

3 Store Multi New 2 Transmission of graphic data to unknown data base server needs

to set requirements for no hardcopies, data security, etc.

4 Border Multi New 2 HTTPS web to unknown doc mgmt. solution are sensitive data,

need security requirements. Port 445 to new server rule 17772 at

FW

5 Flow Multi Accepted 0 HTTPS communication

6 Store Multi New 2 How is data at rest on ICM workstation controlled?

7 Store Multi New 2 How is data on RODS controlled? Will this be a candidate for

Oracle ASO?

8 Store Multi New 2 How is data at rest on CM DB controlled? Will this be a candidate

for Oracle ASO?

Score 11

The scoring is simple: data can fall under no regulation, a single regulatory regime, or multiple regimes,

scoring 0, 1, or 2 respectively. This is because controls on multi‐regulation data have the potential to be more

complex. For example, PCI data is required to be in its own secure subnet, while FDA regulations do not have

this requirement, but require careful nonrepudiation and data tracking mechanisms. Risks can be either

already Accepted (legacy) or New scoring 0 or 1. So each line can score 0, 1, or 2 points. Other scoring criteria

are perfectly acceptable – it’s simply important for the enterprise that whatever scoring mechanism is adopted

be employed consistently in order that relative ratings are built up over time.

When this architecture is adopted by the enterprise its pre‐acceptance data tab is stored to show “real”

risk, and a copy of the worksheet with scores set to Accepted is used for future changes. In this way the “real”

risk scores of an application over time can be tracked (hopefully going down), while the “risk cost” to the

enterprise of a new architecture can be assessed during development.

Applied consistently over time, the rating values offer an indication of the increase or decrease in risk in

the enterprise. Unlike the Change Control page, this more comprehensive risk valuation is displayed to

encourage reduction in risk. Since an ARC usually addresses tactical‐level, version‐change application edits, a

greater emphasis can be placed on risk reduction than can be done during the operational process of bug fixes

and firmware upgrades that comprise the majority of Change Control processes.




Additionally, this process now assigns ownership to risk, an important step towards process maturity. Both

the assignment of risk to business owners, and the collection of risk measurements, is important components

of the knowledge creation that allows the enterprise to make informed judgments regarding enterprise risk.

5.2.1.3 SDLC

Any enterprise that produces its own software should institute a software development lifecycle (SDLC),

even of the most basic sort. For example, even if the only “programming” that takes place is the creation of

maintenance scripts for system administration, a formal process of collecting and documenting the business

and security requirements of the software should be instituted, and the resulting code reviewed by someone

other than the author for compliance with these requirements and for basic errors. The STAR tracks existence

and purpose

of

this

software,

including

periodic

reviews

of

its

continued

necessity,

functionality

and

security.

Change Control and ARC processes are usually binary, yes/no approval processes. More granular and

complicated is the software development life cycle (SDLC) wherein applications are conceptualized, designed,

written, tested, quality checked and placed into production (Figure 7). Initial business requirements are

approved by the Architecture Review Council (ARC), designed and built, tested for functional correctness

during build, then quality checked to assure that all the business requirements are met before being placed

into production. Post‐production bugs are fixed through the Change Control process. New business

requirements, such as new features demanded by users, may call for a new version of the software. In this case

the program must proceed through the entire development process must be reviewed by the ARC and

extensive changes made that require.

Figure 7. Basic SDLC

The integration of the STAR document into the SDLC complicated that process only somewhat.




Figure 8.

SDLC

with

Security

Formal software development requires one of a number of more methodical formal software development

and tracking processes, particularly if the software is for use as COTS outside the enterprise. Additionally, the

software function may dictate compliance with various self ‐ or governmental regulations. For example,

software used in the production of pharmaceuticals is subject to strict Food and Drug Administration (FDA)

Code of Federal Regulations (21 CFR Part 11) regarding tracking the production process as well as signatures of

responsible parties.

While they’re depicted as separate to illustrate their addition to the process (Figure 8), Security

Requirements (derived from high‐water‐mark controls assembled from regulatory compliance requirements

and the concerns of “real” security) are simply an addendum to the overall Business Requirements. As such,

they are introduced at project Inception, and revisited anytime a new version of the program is planned. Note

that Security is added to Functional testing in the Build process – these are tests for common security‐related

programming errors.

Such errors are the focus of the Open Web Application Security Project (OWASP), a nonprofit organization

dedicated to the improvement of security in application development. Periodically OWASP releases its “OWASP

Top Ten”

most

common

application

development

errors.

The

OWASP

2010

release

includes:




1. Injection

2. Cross‐Site Scripting (XSS)

3. Broken Authentication and Session Management

4. Insecure Direct Object References

5.

Cross‐

Site

Request

Forgery

(CSRF)

6. Security Misconfiguration

7. Insecure Cryptographic Storage

8. Failure to Restrict URL Access

9. Insufficient Transport Layer Protection

10. Invalidated Redirects and Forwards

The mission of OWASP is not trivial. According to a recent study (Sappidi, Curtis, & Szynkarski, 2011)

application coding errors cost an average of $3.61 apiece to repair, with the very popular Java EE language

being the most expensive at $5.42 apiece. This valuation, called “technical debt” or “IT debt,” is estimated at

$500

billion

worldwide

(Thibodeau,

2011).

Correcting

errors

before

release

cannot

only

reduce

the

risk

of

a

security breach for an enterprise, but save the direct costs repairing bugs.

The final review of the application before placing software in production should include a thorough

penetration test against the pre‐production software in a setting as close to production as possible. For

external‐facing websites (websites exposed to the entire Internet) a full web penetration test is advisable…

because as soon as this application is exposed to the web some automated illicit software on the Internet will

without doubt do exactly that.

When

the

application

is

ready

to

be

placed

into

production,

security

requirements

are

reviewed

(as

with

business requirements) to confirm that all requirements have been met. If they have, the application is

“certified,” meaning that it has met all security requirements, and the remaining application risk has been

assessed. When the application owner signs off on placing the application into production, it is “accredited,”

meaning that its risks have been accepted by the enterprise as a part of doing business. This certification and

accreditation (C&A) process is a requirement of all enterprises regulated by the United States federal

government (Taylor, 2003).

The assessment of risk, and the enumeration and tracking of software errors, bug reports, and risk

acknowledgement by the enterprise are all part of helping an enterprise move up the scale of the Capability

Maturity Model. Establishing rigorous requirements, requiring clear development steps, and tracking results

allow an organization to move to a Managed (CMMI level 2) environment, and then to a Defined (CMMI 3) and

Quantitatively Managed (CMMI 4) environment. Clearly, without metrics quantitative management is

impossible.




The final step in the SDLC process is to tie funding into the SDLC, dependent upon meeting the

requirements for the various stages. At a minimum, establishing ‘funding gates’ after Inception and before

Production helps reduce the risk of the enterprise wasting money building or deploying into production

applications which do not meet enterprise business or security requirements.

5.2.2 Identity Management

In any enterprise of size an identity management (IdM) system is an essential means of applying and

tracking security settings to individual users across all platforms. Without IdM it is very difficult to coordinate

the rights assigned to a UserID on one platform with the rights assigned for that same person’s UserID on

another platform. A centralized Authentication (AuthN) mechanism such as a single common LDAP or Active

Directory server

will

not

address

the

problem

of

divergent

authorizations.

These

protocols

do

not

provide

centralized Authorization (AuthR) because LDAP and Active Directory are not designed as Authorization

mechanisms.

In addition to the process of technical management of platform UserIDs, there is the analog, real‐life

process of identity management, everything from designing conflict‐of ‐interest rules for enterprise processes

(such as authorizing the creation of new UserIDs and creating the new UserIDs) to assigning space and

equipment (provisioning). Security needs to document the IdM processes, both technical and real‐life, and

conduct periodic reviews to ensure compliance.

5.2.3 RecordsManagement and Destruction

Records management (RM) is the practice of identifying, classifying, archiving, preserving and destroying

records. The Sarbanes‐Oxley Act (SOX), FDA regulations (Federal Drug Administration, 2000), and the Federal

Rules of Civil Procedure require an enterprise possess knowledge of the storage and retrievability of electronic

records. In addition to complying with the law, having a retention policy allows for freeing up storage space as

records are routinely deleted in accordance with law and policy (Leavitt, 2007).

However the

file

destruction

policy

must

be

suspended

upon

receipt

of

notification

of

litigation,

or

when

litigation is reasonably anticipated.

5.2.3.1 Datadestruction policies

In the event of a court order to produce evidence, such as at the initiation of a suit, the keys to enterprise

data destruction policies are documentation and consistency. In order to provide the greatest protection




against court‐imposed sanctions, the data destruction policy needs to address how to classify and handle each

type of data the enterprise possesses, and what kinds of data can be removed. Media containing sensitive data

requires the most strict controls and destruction methods to ensure the data cannot be forensically recovered.

See the section below labeled Equipment Disposal.

Types of information to consider for individual retention and destruction policies include:

Email;

Internet browser information (cached files, cookies, download records);

Word processing documents, spreadsheet, and presentations;

Databases;

Text messages/instant messaging/chat records;

Scans and electronic faxes;

Electronic calendars;

Voicemail;

Blogs;

Bulletin board postings.

Depending on how the enterprise conducts its operations, these and other data types may require special

handling to ensure proper management and disposal.

5.2.4 Incident handling

An important component of any enterprise is its ability to handle incidents, defined as events that require

oversight, evaluation and possibly correction. An incident can be as trivial as a printer running out of toner to a

major network

failure.

Any

event

that

cannot

be

handled

by

a regular

employee

but

which

does

not

require

calling emergency first responders can and should be tracked by a trouble ticket system. Emergency events,

ones that require calling emergency first responders, must be handled through a separate emergency response

process.

5.2.4.1 TroubleTickets

The Trouble Ticket system provides a means by which the enterprise may learn, through analysis of the

incident tracking reports. It is a primary method of creating knowledge and measurable statistics (metrics)

regarding the enterprise. Therefore it is important to institute a trouble ticket system if one does not already

exist, and to review it and update it to measure items that can be studied to determine changes in the security

of the enterprise.




5.2.4.2 Equipment Disposal

There are many means of disposing of electronic media – the hardware on which sensitive information may

be

stored.

Different

techniques

may

be

required

for

the

different

types

of

hardware:

Cell phones, BlackBerrys, iPhones, Palm Pilots and Pocket PCs

Hard Drives

Flash Memory Devices

CDs and DVDs

Tapes and floppy disks

Physical destruction of print media usually involves shredding. Additionally specialized services offer

shredding of all the other media types listed. If your enterprise does not want to pay for shredding of hard

drives then it must employ degaussing or data‐overwrite methods. Degaussing equipment, which erases a hard

drive by generating a very powerful magnetic field, is quite expensive. Data‐overwrite software, which

repeatedly writes random data over the entire surface of the hard drive, can be obtained for free, but is time

consuming since it is limited to the read/write speed of the hard drives.

5.3 Information Security Techniques

Information security techniques are methods for successfully implementing information security policy,

processes and standards. Multiple techniques can be available to meet a particular goal, and the selection of

which technique to apply is a measure of the culture of the enterprise. For example, one technique for keeping

the network secure from unauthorized wireless access is to use encryption to prohibit connection by anyone

lacking the encryption key. Another technique is to provide a separate guest wireless network for visitors. Both

accomplish the goal of security, but one provides guests access and another does not.

5.3.1 Vulnerability Management

A vulnerability program addresses risk through assessment and resolution of known vulnerabilities while

taking steps to reduce the impact of exploitation of unknown vulnerabilities. Before conducting a vulnerability

assessment the enterprise should have a list of system owners as well as a policy requiring system owners to

address vulnerabilities

uncovered

by

the

assessment.

This

latter

is

non

‐trivial:

owners

of

production

platforms

are frequently concerned that vulnerability remediation – known as “patching” – will somehow break their

systems. The solution of course is testing, but some enterprises either lack a sufficiently robust testing

environment to provide confidence that patches to production will not create problems, and others simply lack

the personnel resources to add patch testing to the schedule of their IT personnel. The alternative of course is

to leave known vulnerabilities, in place, vulnerabilities for which there are frequently exploits – that is to say,




programs designed to breach the CIA of your platform using a specific vulnerability or set of vulnerabilities –

known to be scanning Internet‐connected platforms for targets (aka “in the wild”). Part of the reason for this

unreasonable resistance is responsibility – if a system administrator takes down a service for patching and has

trouble restoring operations, the system administrator is concerned that they will be blamed for the outage. If

a third party takes down a service with an exploit, they are to blame rather than the system administrator.

Even if the administrator is not blamed, they are often the ones who have to struggle to return a system to

service. So despite the existence of known threats to known vulnerabilities, implementing a robust patching

program still meets considerable resistance.

It is important in these cases to present the efforts of the security administrators as collaborative, rather

than proscriptive. Ideas to consider include rolling out patches as part of other scheduled changes that are

likely to

take

the

service

offline

In addition to patching, regular proactive assessments are part of Vulnerability Assessment, including in‐

house and third‐party Penetration Testing, which actively seek to exploit vulnerabilities found during the

scanning process. Like patching, this frequently does not sit well with system and database administrators,

since they want neither the blame for their systems being taken offline, nor the responsibility for restoring

order following a particularly effective penetration test. If, for example, an attacker uses an SQL exploit to drop

a table from the database, that table will need to be restored.

While recovering

from

an

outage

is

in

itself

a test

of

the

Business

Continuity

Plan

and

the

ability

to

restore

from backups is part of basic operational requirements, system administrators and application owners are not

eager to test these capabilities.

In addition to a bringing a collaborative approach to these concerns, security personnel can also instill

confidence by calling for regular tests of the Business Continuity Plan, and for regular tests of restoration from

backup. In many enterprises these functions may rarely be tested, so anxieties can be eased by turning these

into regular, periodic chores. With greater confidence in their ability to restore from backup and to restore

according

to

the

BCP,

system

administrators

will

have

less

anxiety

about

recovering

from

successful

penetration testing.

Resistance overcome, vulnerability management is another source of knowledge about the enterprise.

Metrics that can be derived include numbers of vulnerabilities uncovered during past vulnerability assessments

and penetration tests, recurring vulnerabilities, leading categories of vulnerabilities (database exploits, web

exploits, DDOS vulnerabilities, etc.), severity levels, time to recovery following a successful attack, and number




of anomalous systems and services – those not appearing in the system administrator’s lists, or new since the

last scan – were discovered.

For the security team, metrics indicating a consistent and decreasing number of vulnerabilities are a

welcome indicator of progress. For the enterprise, such figures can help justify the expense of the security

program.

5.3.1.1 Threat Modeling

Threat Modeling involves examining the paths by which attackers might penetrate enterprise security, not

in search of vulnerabilities in code or configuration, but for the more likely paths by which to detect an attack

underway.

Threat modeling takes three primary approaches – Attacker based, Application based, and Asset based.

Attacker‐based threat modeling begins by considering the motivation of the attacker – what might an attacker

be seeking in the enterprise? Application‐based threat modeling begins by analyzing the design of an

application using a framework such as Microsoft’s STRIDE approach (Hernan S. , Lambert, Ostwald, & Shostack,

2006).

STRIDE is an acronym based on categories of security threats (Table 5):

Table 5. STRIDE Threats and Properties

Threat

Definition

Security Property

Spoofing Falsifying network identity Authentication

Tampering Altering data Integrity

Repudiation Denying responsibility for a communication Non‐Repudiation

Information Disclosure Violating secrecy or privacy Confidentiality

Denial of Service Preventing authorized access Availability

Elevation

of

Privilege

Gaining

excessive

access

rights

Authorization

Asset based threat modeling begins by identifying critical assets (those essential to the operations of the

enterprise) and valuable assets (which can easily be exchanged for cash) and determining the likeliest attacks

on these assets, then examining the security controls on the assets.

Threat modeling can be carried out on an as‐needed basis or as part of either a periodic or pre‐production

a vulnerability assessment. Additionally, during software design threat modeling is an important means of




prioritizing development efforts aimed at reducing vulnerabilities. If an application is going to be subject to a

service‐level agreement (SLA) requiring high availability, modeling threats to availability should be a high

priority.

Threat modeling results also serve as a source of knowledge for the enterprise, and accumulated reports

can be analyzed as an indicator of the progress of the enterprise security program.

5.4 Information Security Promotion, Awareness,and Training

As a comparatively new addition to the landscape of business operations, information security has to adopt

an aggressive “sales” posture. Human Resources doesn’t have to explain what it does for an enterprise, and

neither does Accounting, but Information Security still does, so outreach and awareness are more important

for

Information

Security

than

for

other

portions

of

the

enterprise.

Promotion can include such passive approaches as enterprise intranet (internal network) websites, e‐mail

and paper newsletters, flyers, and posters. Awareness includes outreach, such as “National Cyber Security

Awareness Month4” information kiosks, interactive security training videos, voicemail and e‐mail company

announcements, and presentations customized to various enterprise business groups including senior

management, project management, software developers, etc. Training involves developing required, periodic

training exercises to be required of all personnel as a condition of employment.

5.4.1 AwarenessProgram

According to the National Institute of Standards, “people are one of the weakest links in attempts to secure

systems and networks (National Institute of Standards and Technology, 2003).”

An enterprise information security awareness program is important to ensure that all users and managers

of IT systems understand their roles and responsibilities related to the mission of the enterprise, the enterprise

security policies, procedures, and practices, and have at least adequate knowledge of the security controls

required to protect IT resources.

Recognizing their importance, most major InfoSec regulatory programs require enterprise information

security awareness programs, including HIPAA, the Sarbanes‐Oxley Act (SOX), the Gramm‐Leach‐Bliley

Amendment (GLBA), and the Federal Information Security Management Act (FISMA).

4 Created by the Department of Homeland Security http://www.dhs.gov/files/programs/gc_1158611596104.shtm




5.5 Information Security Policies

Information security policies are similar to standards in that they translate strategic security goals into

tactical

rules,

regulations,

and

objectives

that

direct

the

enterprise

towards

improved

security

outcomes.

High

level strategic policies include statements such as “The enterprise shall employ multi‐factor authentication,

Tactical policies such as “Any multi factor authentication implemented shall be affordable and will not unduly

slow the authentication process.” Operational policies may include such details as “Any multi factor

authentication solution shall integrate with Microsoft Active Directory an LDAP servers.”

These policies may in turn lead to standards such as “The enterprise employs Acme Fobs for multi factor

authentication” because this product meets all the policy requirements stipulated.

5.5.1 PoliciesInformation security policies provide the foundation for an effective information security program. Policies

are management directives that establish the business goals of the enterprise in order to manage the risk that

the enterprise incurs as it pursues its goals.

5.5.2 People

The first steps to security are the people. Authorization and Authentication exist to help link authenticated

individuals to

authorized

access

rights,

but

if

the

people

themselves

are

not

trustworthy,

competent,

and

properly trained they will pose a risk to the enterprise. The elements that help reduce the risk posed by

personnel are

Policies and Procedures – efficiency and clarity of operations to help reduce mistakes

Training and Awareness – appropriate training and regular reminders to reduce errors and incidents

System Security Administration – properly configured equipment for user productivity and efficiency

Physical Security – personnel access control, asset loss prevention, safety and emergency procedures

Personnel Security – HR checks and requirements, clear security policies, reward/penalty programs

Facilities Countermeasures – incident response measures, from fire suppression to detecting hacking

5.5.3 Password

Policies

Passwords are simply one kind of “Something You Know” factor in the authentication process. Since single‐

factor authentication alone is arguably unacceptably weak in any circumstance, the precise degree of security

offered by various password schemes constitutes splitting hairs. Common password schemes involve

mandating a mix of upper‐ and lower‐case letters, numbers, and symbols, in order to maximize the solution

space (the number of different possible combinations.) Unfortunately the tradeoff between security and ease




of recall means that passwords are either less complicated than would be optimal, or are too difficult for users

to recall, resulting in the passwords being written down, or constructed in a repeatable fashion, or other

methods taken that compromise the security offered by the password.

Many students of password security argue that longer, easier‐to‐remember pass‐phrases offer better

security than passwords, simply due to length. For example a typical “strong password” featuring eleven

random characters, upper‐and‐lower cases, and symbols offers 28 bits of entropy and would take about three

days to guess at 1000 guesses per second. On the other hand, a more‐easily‐remembered four word phrase,

including only lower case characters, provides 44 bits of entropy and would take 550 years to guess at the

same pace (Monroe, 2011).

Whatever password policy is implemented, it is important to develop a multifactor authentication policy to

augment enterprise security.

5.5.4 Enterprise Architecture

Building an Enterprise Architecture practice is important in order to connect the enterprise’s business

drivers with its technology infrastructure. Enterprise Architecture brings together strategy, business and

technology to allow an enterprise to see its current operating scenario and to plan for future operations.

Enterprise Architecture integrates IT resource planning, decision‐making, and implementation processes to

identify and

resolve

performance

gaps

across

the

enterprise,

including

in

the

area

of

security.

Security is applied to enterprise architecture as a thread weaving through all levels of the EA framework

because security is integral to strategic initiatives, business services, information flows, and applications and

technology infrastructure. Security under enterprise architecture is divided into four groups, Information

Security, Personnel Security, Operational Security, and Physical Security.

While an Enterprise Architecture practice is a valuable resource for a robust Security Program, its

development is a long‐term strategic investment that will comprehensively affect the enterprise.

5.5.5 Outsourcing

Whether hiring an overseas call center, using “cloud” services, or contracting a local training firm to teach a

class, an enterprise needs to balance both risk and cost when seeking to outsource any functions it might

otherwise carry out itself. Many times outsourcing provides access to specialized knowledge, services, or best




practices or offer superior availability. Concerns exist surrounding data confidentiality, the qualifications and

expertise of personnel, and the risk of dependency upon a third party for critical business functions.

Additionally an enterprise may wish to outsource security operations, particularly those of middle or small

size that may not possess the skills, knowledge, and personnel required for effective security management

(Karyda & Mitrou, 2006). Managed Security Service Providers (MSSP’s) provide such services as intrusion

monitoring, e‐mail virus and spam filtering, penetration testing, IT auditing, firewall configuration and

management, virus protection, intrusion detection systems management, server management, network

monitoring, security policy development and application, security education and training, security upgrades,

VPN management, user access management, data classification, contingency planning, business continuity

planning and disaster recovery, network boundary protection, managed services for firewalls, incident

management, including

emergency

response,

and

penetration

testing,

content

filtering

services,

data

archiving

and restoration.

While the services of an MSSP may enable an enterprise to undertake security measures that might

otherwise be unavailable to it, outsourcing entails the risk that the enterprise may not develop its own security

awareness and expertise. Enterprises that outsource security may be unable to manage security risk (Deloitte,

April, 2005).

5.5.6 Legal requirements

Legal drivers include observing all applicable laws. The rate of increase of complexity of this apparently

simple requirement – don’t break any laws – is considerable, and the reason lawyers are so well‐paid. The

simple legal requirements of a small business in a single city start to expand as soon as the business crosses

state lines and must comply with Federal laws, including interstate commerce laws. For example, the California

Database Breach Act, state Civil Codes 1798.29 and 1798.92, contains strict requirements regarding notifying

citizens of California when the privacy of their data is compromised (Data Governance Institute, 2008)

[emphasis added]:

Beginning

on

July

1

of

2003,

state

government

agencies

as

well

as

companies

and

nonprofit

organizations regardless of geographic location must notify California customers if personal

information maintained in computerized data files have been compromised by unauthorized

access.

California consumers must be notified when their name is illegitimately obtained from a server or

database with other personal information such as their Social Security number, driver's license

number, account number, credit or debit card number, or security code or password for accessing

their financial account.




The impact of such a requirement on a small business deciding to do business in California for the first time

would be significant, particularly if it is based in Alabama, Kentucky, New Mexico, or South Dakota, the few

states lacking such laws (National Conference of State Legislatures, 2010). Then there are international laws,

both international commerce as well as the laws of the nations and municipalities of the nation itself.

This has profound implications for information security. The United States is what is termed a “surveillance

society,” (Lyon, 2001) where laws such as the US Patriot Act (Electronic Privacy Information Center, 2001) allow

for government interception of electronic communications without formal legal proceedings (Henderson,

2011). Meanwhile the European Union is strongly focused on individual privacy (Europa Summaries of EU

Legislation, 2011), resulting in “an inherent contradiction, exacerbated by the vastly different approaches

nations employ in their attempt to regulate the Internet and e‐commerce.” (Krup & Movius, 2009). Whereas in

the EU,

it

is

the

responsibility

of

the

government

to

protect

citizens’

right

to

privacy,

in

the

U.S.,

markets

and

self ‐regulation, and not law, shape information privacy. In the EU, privacy is seen as a fundamental human

right; in the U.S., privacy is seen as a commodity subject to the market and is cast in economic terms (Kobrin,

2004).

To address this conflict, in 2000 the United States and the European Union entered into the “Safe Harbor”

agreement (Connolly, 2008):

The US Safe Harbor is an agreement between the European Commission and the United States

Department of Commerce that enables organizations to join a Safe Harbor List to demonstrate

their compliance

with

the

European

Union

Data

Protection

Directive.

This

allows

the

transfer

of

personal data to the US in circumstances where the transfer would otherwise not meet the

European adequacy test for privacy protection.

The Safe Harbor is best described as an uneasy compromise between the comprehensive

legislative approach adopted by European nations and the self–regulatory approach preferred by

the US. The Safe Harbor Framework has been the subject of ongoing criticism, including two

previous reviews (2002 and 2004). Those reviews expressed serious concerns about the

effectiveness of the Safe Harbor as a privacy protection mechanism.

As Connolly describes, and further confirms in the 2008 report, Safe Harbor has been unevenly

implemented and

enforced

over

the

past

decade.

My personal experience as Chief International Security Architect for a major retail corporation based in

Minnesota is that these requirements are probably impossible to fully implement in an operational

organization (see also my comments regarding “guardrails versus roadblocks”). In that case, we were faced

with premiere stores opening in China and the European Union.




Initially the retailer planned on maintaining data centers in all three regions. This presented the risk –

actually the certainty, since the Chinese government would otherwise thwart its construction – that

undercover Chinese intelligence agents would be present in the Beijing data center. An additional risk pointed

out in a memo to the corporation’s Board of Directors was that of Chinese employees using enterprise network

channels to bypass the firewall behind which China sequesters its citizens, making the company a partner to

these violations of Chinese law. A final risk was that China would carry out attacks against both the company as

well as third parties using the corporate network ‐ the modus operandi for cyber‐attacks by Chinese agencies

(Deibert, R. & Rohozinski, R., 2009).

These unexpected (by the Board) risks, as well as financial considerations, resulted in the decision to

employ a single U.S. data center. However, this came with its own risks and expenses. Originally the China,

Europe and

U.S.

data

centers

had

been

intended

as

backups

for

each

other

in

case

of

a catastrophic

failure

at

any one location: now a U.S. based “hot” (continuously ready) backup site was required. The U.S. data center

had to comply with expensive Safe Harbor data requirements for hosting European data. Additionally the data

center had to operate on a continuous schedule, 24 hours per day, seven days a week, 365 days a year

(24/7/365) further increasing costs over the original design that anticipated regular business hours in each

location.

As this example demonstrates, balancing laws against security concerns while meeting enterprise goals is a

considerable

exercise

in

Risk

Analysis

and

Risk

Management.

5.5.6.1 E ‐Discovery E‐Discovery is the process of responding to a court ordered Demand for Production of Documents (DPD) in

the form of electronic information and records, also called electronically stored information (ESI). To be

effective at retention, the enterprise must know where records are stored. Not knowing can be especially

dangerous, as most large dollar sanctions have involved the sudden appearance of documents not known to

exist earlier in the litigation. Compliance is also critical: if your organization has a 90 day records retention

policy, but

an

employee

arbitrarily

decides

to

delete

all

their

e‐mail

on

a weekly

basis,

the

court

could

sanction

your enterprise for letting potentially relevant e‐mails be destroyed – even if your enterprise was not involved

in litigation at the time the destruction occurred.

In the event of litigation, it is important for an enterprise to be as ready as it can be to comply with a DPD.

E‐Discovery requirements must be taken into account when designing the overall document retention policy

for the organization. Before a DPD is served, the enterprise should have comprehensive retention and risk




management protocols, strong compliance mechanisms for ESI, regulated and enforced personnel document

retention behavior, and IT back‐up and restoration procedures.

An Electronic Discovery Rapid Response team should be assembled in advance, including management, IT,

outside counsel, and a computer forensics provider. An employee should be selected as the designated witness

for Rule 30(b)(6) deposition (Federal Rules of Civil Procedure, 2011), and equipment and personnel should be

ready to create forensic true and complete images of all necessary storage media upon receipt of a DPD.

Personnel need to be trained in both evidence preservation in the event of litigation, as well as need‐to‐know

rules and rules about discussing a case outside of the enterprise (in short: don’t).

Demonstrating to the Court the existence of a reasonable, well thought out, comprehensively distributed

and carefully adhered to and monitored records preservation and retention program with rigorously enforced

penalties for non‐compliance is critical in limiting the risk of sanctions in the event of litigation.

5.5.7 HumanResources

As the EISP is rolled out, the enterprise may need to expand its information security staff, and the Human

Resources department (HR) will need guidance in selecting candidates to review for interviews. There are a

number of industry certifications that HR can use as part of the overall assessment process; Table 6 lists several

leading security certifications.

Table 6. Leading Security Certifications

Certification Meaning Agency Description

CISSP Certified Information

Systems Security

Professional

International Information

Systems Security

Certification Consortium,

known as (ISC)2

Best known, most‐

respected certification,

requires five years of

experience, sitting a six‐

hour test on ten domains

of knowledge, and

providing a professional

recommendation

SSCP Systems Security Certified

Practitioner

International Information

Systems Security

Certification Consortium,

known as (ISC)2

One year of experience,

requires seven

domains

of knowledge

GIAC Platinum Global Information

Assurance Certification

SANS (System

Administration and

Network Security)

Institute

Requires GIAC Gold

certification plus a

proctored 2‐day test.

CISM Certified Information

Security manager

Information Systems

Audit Control Association

Five years of security

experience including




three as a security

manager, and sitting a

proctored exam

Security+ Computer Technology

Industry Association

100 question test

Practically speaking the CISSP has the best recognition value, while the CISM is equivalently demanding but

is newer and lacks the name recognition of the CISSP. The Security+ is a good entry‐level cert, as is GIAC Gold,

while GIAC Platinum falls somewhere in the middle.

Certification alone is of course not a measure of any individual candidates qualifications, but they can serve

as a guideline, and some HR departments use certifications as simple filters, dropping any resume lacking a

CISSP into the shredder. This is just as rash as would be hiring based on certifications alone.

5.5.7.1 Hiring

Just as Human Resources must be provided with criteria by which to evaluate potential employees,

managers must be both capable of evaluating the applicability of potential employees – particularly the first.

There are a number of security roles within any enterprise which must all be covered by the first employee or

employees ((ISC)2, 2005). A few typical information security job titles and experience requirements include:

Security auditor, minimum 5 years of experience

Security specialist, minimum 2 years of experience

Security consultant minimum 5 years of experience

Security administrator,

minimum

2 years

of

experience

Security analyst/engineer, minimum 5 years of experience

Director/manager of security, minimum 7 years of experience

Chief security officer (CSO)/chief information security officer (CISO), 10 years of experience

These roles can be distributed as fiscal resources allow for additional employees, and the need to fill these

roles shall guide the specific hiring requirements for each role. Given the high cost of skilled personnel

resources, a hiring plan is recommended in order to align phases of the anticipated security program with new

hires in a cost‐efficient manner.

6 Op e r a t i o n a l El em e n t s o f a n EI SP

Just as Enterprise Leadership and Management must plan and initiate a security program, the operational

aspects of these plans must be implemented by operational personnel. These are some of the operations that

must be included in these plans.




6.1 Trackingand KnowledgeCreation

The first step to begin moving an organization towards an improved level of maturity is to begin collecting

measurements

of

performance,

or

“metrics.”

For

our

example

medical

enterprise,

we’re

going

to

introduce

the

Security Tracking and Risk document (STAR), implemented as a Microsoft Excel workbook. The function of a

STAR document is to track the security status of enterprise objects such as applications, databases, common

off ‐the‐shelf software (COTS), and infrastructural elements like routers and switches.

6.1.1 STARTracks

A tool such as STAR must track sufficient information for analysis and also for auditing purposes. Therefore

the STAR has the following tabs:

1. Dashboard –

responsible

personnel

and

description

of

the

enterprise

component,

plus

key

results

from

other

tabs

2. Data Classification – all data field types explicitly described as sensitive by the regulations to which the enterprise

is subject, as well as any the enterprise describes as sensitive. This sheet is supported by the hidden worksheet

“Matrix” that serves to identify sensitive data defined by various regulations.

3. Risk Assessment – basic description of the component and its primary areas of risk

4. Security Plan – basic description of the controls to be implemented to address known risks

5. Templates: Risk Plan, Action Plan, and Change templates. Risk plans describe controls to be implemented

following discovery of a particular risk; Action plans track the risk before and after following a Risk plan; Change

Templates evaluate and analyze the risks of changes tracked by the enterprise change management system.

An example STAR has been attached ( Appendix D. STAR Template) for a bioinformatics research

application used by enterprise scientists to find trends in genetic information. As a result it contains sensitive

data such as appropriate demographic data such as race and gender, as well as individual names and genetic

information collected from cheek swabs.

The first tab of the STAR includes basic instructions for regular (non‐security_ employees. The amount of

information collected from regular employees is deliberately kept to a limit. This is to keep to the security

principle “Put down guardrails, not roadblocks.” By carefully limiting the information requested to that which

can be understood and quickly and easily collected, the STAR document does not become a roadblock, and

employees will not be as likely to seek to avoid it. Other tabs of the STAR are filled out by security in

consultation with

related

employees

(such

as

those

listed

in

the

Dashboard

tab)

in

order

to

track

risk.

6.2 Operational requirements

Finally, security has to be balanced against the need for the enterprise to do business. One example is

incident response. If an intrusion detection system (IDS) issues an alert that it picked up the signature of an

illegal access at 3:00 a.m., the ideal solution might be to have someone available to immediately evaluate the

notification. However if the data center is only staffed from 6 a.m. until 8 p.m., adding a third‐shift operator




might be more than the enterprise can afford. And finding qualified responders willing to work third shift can

be a challenge. In the end, the way that the enterprise operates – from 6 a.m. until 8 p.m. – might dictate that

the security solution to this problem is to equip select data center personnel with pagers, and have 3 a.m. IDS

alerts sent to the pagers in the hope of prompt attention in the morning.

Whether this solution would meet all the governmental regulations and industry self ‐regulations to which

the enterprise is subject must be determined by the enterprise legal resource in consultation with the security

team. The legal team must interpret the language of the regulations while the security team to assesses

whether the security control – in this case, off ‐hours pagers for IDS alerts – meets the requirement as

interpreted by the lawyer, while fitting into the operational requirements of the enterprise.

Operational requirements exist, implicitly or explicitly, at all levels of the enterprise, and describe the

processes by which the enterprise does business. When are the hours of operation? What services does the IT

department provide and how are they accounted? What platforms are supported for servers, or workstations?

What service level agreements (SLA) exist to help prioritize responses to server downtime? What is the

architecture of the enterprise computer network? Operational and security requirements feed and change

each other – a security requirement may dictate a change in operations, an operational requirement may call

for one type of security control rather than another. And whatever is resolved between security and

operational requirements, these must meet all laws and regulations to which the enterprise is subject.

6.3 Firewall Configuration

and

Change

Firewall configuration is often a challenge when instituting an EISP, because of firewall rules that have

accumulated over time (legacy firewall rules). The enterprise is frequently very careful about disabling any of

the firewall openings for fear of impacting an existing production service. Without documented justification for

each rule and clear conditions for rule expiration, obsolete rules will accumulate for fear of potentially

impacting a production service, leaving openings in the firewall to be exploited.

This concern arises when firewall rules exist without corresponding business justification and the process

of altering

how

firewall

rules

are

managed

can

impact

several

areas

of

the

enterprise.

For

a very

large

enterprise with multiple business partners, business centers, and clusters of firewalls, implementing a single

simple change can imperil the carefully coordinated set of servers and services. And business partners with

contracts specifying a particular service level agreement (SLA) will not be forgiving of interruptions in service

that violate their SLA contracts.




But for even small enterprises with simpler firewall architectures, some elements must be in place in order

to responsibly manage changes to firewall rules (Maschak, 2003):

1. Justification for each firewall rule. This involves surveying all firewall rules that lack such justification, a

tedious process of tracing down applications and servers and service owners. One temptation is to

instead monitor all traffic through the firewall for a set period (a quarter or a year) and then close off

all unused open ports. There are risks that active traffic could be unjustified – an illicit server running

on the network ‐ or that a particular communication may take place outside however generous a time

window. It is generally advisable to assemble the justifications for as many firewall rules as possible

before disabling unused rules that cannot be justified.

2. Comprehensive documentation of all firewall rules. The justifications for all firewall rules must be

compiled, and

this

compiled

rule

set

must

be

appropriately

secured,

but

available

to

authorized

individuals. Such rules need to include the following:

a. Name of rule

b. Purpose of rule

c. Functional owner of rule – for what enterprise service does this rule exist and who owns that

service?

d. Custodian of rule – what firewall administrator will be responsible for this rule. This will be the

first person contacted when the rule seems to have failed.

e. Rule expiration – periodic review will be required by change control policy, but a maximum

lifetime for a given rule must be required. At the end of this expiration date the service must be

reviewed to

ensure

it

still

requires

this

firewall

rule.

3. A change control process. A system of creating “event tickets” or “trouble tickets” to track requests for

firewall changes, as well as a documented approval process that controls for conflict‐of ‐interest

(making sure someone can’t authorize and conduct their own changes) and updating rule

documentation.

4. A testing process and environment that is appropriate to the size of the enterprise and its firewall

environment. The testing environment not only must match as closely as possible the production

environment, but will require the full firewall‐rule justification documentation, in order to be able to

test all valid rules against the proposed changes.

Once these elements are in place – justification, documentation, change control and testing ‐ firewall rules

can be created, changed, and expired in a controlled and predictable fashion that minimizes risk. Of these the

most troublesome challenge addressed is the expiration of firewall rules.




This is an example of one of the many operational processes that will be impacted by the development of a

comprehensive EISP.

6.3.1 Emergency Response

Processes

The safety of personnel is the unquestionable first priority in emergency response procedures, and these

involve certain elements of information management. The following are some general elements that need to

be developed, maintained, and included in periodic emergency training:

Evacuation and safety drills;

Call trees of emergency personnel to be contacted in the event of an emergency;

Methods of accounting for all personnel following an emergency.

Communications rules following an emergency;

The means of deciding whether to activate the business continuity plan and/or disaster recovery procedures.

6.3.2 BusinessContinuity Planning/Disaster Recovery

Intended to begin immediately AFTER the safety of all personnel is assured and the immediate crisis is over,

the goal of the Business Continuity Plan/Disaster Recovery (BCP/DR) plan is to minimize the duration of a

serious disruption to business operations, facilitate effective co‐ordination of recovery tasks, and reduce the

complexity of the recovery effort. Information management elements inherent in BCP/DR process include:

Contact information of key personnel and “understudy” personnel

Call trees of all personnel to be contacted in order to assure a full accounting of personnel

Communications plans for handling inquiries from news media

Alternate communications and meeting‐places during service outage of primary resources

Means of authorizing extraordinary expenditures for addressing emergency

Prioritized list of key services to be restored

Prioritized list of key vendors and customers to be contacted

6.4 Compliancevs.“Real” security

While attempting to balances all the factors that affect enterprise security, the concept of ‘real’ security

sometimes seems like an afterthought. If the best you can get after factoring all the laws, regulations, and

requirements of the enterprise is a solution that’s shaped like a security spoon, it can be frustrating to recall

that your

original

goal

was

a security

fork.

Then,

to

dangerously

overextend

the

metaphor,

what

is

the

optimal

security solution for the enterprise: a security fork, a security spoon, or some kind of security spork?

6.5 Security Assessment

A comprehensive security assessment methodology is required to assist in

evaluating security policies and procedures; provide a method to determine the current




status of security programs relative to existing policy; and establish targets for improvement. The example

Framework in Appendix C. Security Assessment Framework may be used to assess the status of security

controls for information; individual systems (e.g., major applications, general support systems, mission critical

systems); a related group of systems that support operational programs; or the operational programs

themselves. Assessing all security controls and all interconnected systems that an asset depends on produces a

picture of both the security condition of a component and of the entire enterprise.

7 Co n c l u s i o n

This book has presented the overall structure of the EISP, including defining security, describing defense‐in‐

depth, and exploring the strategic, tactical, and operational elements that contribute to the overall EISP effort.

We’ve examined the strategic role of the CISO and how that role ought to properly be placed in the

management structure. We’ve also explored the key philosophy guiding the development of this EISP, “to put

down guard rails, not road blocks.” By getting to know the corporate culture, and properly assessing the

process maturity of the enterprise, the CISO or other security officer has the best chance of developing an EISP

that will successfully reduce risk in the enterprise.

We’ve reviewed the development of tactical processes to ensure the EISP has longevity in the enterprise.

By developing standards, processes, polices and techniques that fit the corporate culture, one can develop

ongoing training

and

monitoring

to

ensure

that

the

EISP

will

be

maintained

and

observed

going

forward.

And we’ve examined the operational elements of the EISP, including how to create knowledge within the

enterprise in order to provide measurable risk metrics to facilitate decision‐making, track regulatory

compliance, and even manage “real” security.

The primary differences between this EISP and the current best practices of industry include the

recommendation that the CISO be removed from its traditional reporting structure under the CIO or VP of IT,

and shifted to reporting to the CFO. When reporting to the CFO, risk analysis can assist with financial decisions

and the

CISO

can

link

the

funding

of

projects

to

adherence

with

the

EISP.

Additionally,

this

EISP

advocates

the

“guard rails not road blocks” philosophy that recognizes that the mission of the enterprise, its business drivers,

must be facilitated, or the EISP will not be successful.

8 A p p e n d i x A . EI SP Pr o j e c t Ch a r t e r

EISP Charter.docx




9 A p p e n d i x B . Ex am p l e EI SP

EISP Example.docx

1 0 A p p e n d i x C. Se c u r i t y A s se s sm e n t Fr a m e w o r k

EISP Assessment Framework.docx

1 1 A p p e n d i x D . ST AR T em p l a t e

EISP STAR Template.xls

1 2 A p p e n d i x E. Ba d g e s a n d U se r I D s

12.1.1 Badges

Managing identity – the set facts that when combined serve to link a UserID to a person across all aspects

of an enterprise ‐ is an extremely important part of authentication, and the information displayed on badges

presents often‐overlooked confidentiality problems. Consider the following name badges. The badge in Figure

2 presents two Confidentiality vulnerabilities in that it reveals both more information about the individual (a

privacy violation) and about the enterprise (a confidentiality violation) than is strictly necessary to do its job.

The badge in Figure 9 gives the badge‐holder’s full name (“Alice Anderson”) as well as her department

(“Academic Computing Services”) and even job (“Help Desk”). The full name comprises a violation of the

employee’s privacy.

Someone

with

a more

unusual

name

than

“Anderson”

could

even

be

vulnerable

to

having

their home invaded while they are observed by some perpetrator to be at work. Or possibly Alice might be

noticed by someone who sees her out for lunch, and now can stalk her all the way back to her desk based on

the information on her badge. Whatever the scenario, it is facilitated by a badge that reveals more information

than it needs to in order to serve its function.

What is the function of the badge? Again, it is an authentication tool, linking the

person, Alice, to the digital identity embedded in the badge. The picture is designed to

allow a human

to

visually

authenticate

her

identity,

possibly

by

cross

referencing

an

enterprise database of employee photos, or against a government ID such as a driver’s

license. Once assured that the person holding the badge is legitimate, the badge

authenticates Alice to the unique digital ID stored in the electronics of the badge, which

is then read by a door scanner or other device. Figure 9. Full Name




Figure 10. Last Name

The badge in Figure 9 also facilitates “phishing” attacks against the enterprise. Phishing is a fancy new

handle for “fraud” or “grifting,” as applied to computer systems. For example, someone in a restaurant who

sees Alice’s badge might simply phone the Help Desk while Alice is at lunch and claim that she had been

helping them with a password reset before being disconnected, and could the kind person please finish

resetting the password on account “ABC123” to “pickle.” This claim of privy knowledge, turning upon the

absent Alice’s authority, might be enough to trick a coworker into changing the password without first speaking

to Alice.

The badge in Figure 10 is an improvement. Alice’s job is no longer visible, and her name is reduced to A.

Anderson. However, this introduces a new problem – A. Anderson is not specific enough, and the name is too

general. Since Alice’s gender is (presumably) obvious when meeting her in person, there is no advantage to

concealing it

on

her

badge

by

abbreviating

her

first

name.

And

adding

males

doubles

the

number of people who could conceivably alter her badge by

pasting a quick picture over Alice’s own (an integrity

violation). Certainly the name could also be changed, but the

more changes required the more likely the change is to be

spotted. While these are slim vulnerabilities, if we’re trying

to secure the enterprise then these minor changes are worth

exploring if they all come at the same price.

The badge that best preserves privacy in authentication

is that in Figure 11. Since, as mentioned, Alice’s gender is likely apparent in person, no extra information is

given out by revealing her first name. Her department probably provides enough information to locate her if

necessary by asking for “Alice A.,” without giving out enough information for a stalker or burglar to determine

specifically where she works or lives. And a phishing attack that asked for “Alice in Academic Computing

Services” is less likely to sound authoritative than one using her full name and specific job. The final badge,

therefore, provides sufficient information to accomplish its job of authenticating its bearer, without giving

away surplus

information

that

can

render

the

enterprise,

or

Alice,

vulnerable.

And of course the concern that Alice might forget her badge at home is a threat to her availability, as she

might not be able to get into her workplace.

Figure 11.

First

Name




12.1.2 UserID

In the case of a badge, we can make assumptions about the bearer that do not apply to a UserID. A badge

is

normally

carried

by

its

bearer,

and

that

person’s

gender

and

first

name

are

more

often

available

than

not.

If

someone addressed Alice in a public setting, she would more usually be called “Alice” than “Anderson.”

The opposite is true for UserIDs, which are anonymous, and are not visibly associated with their owner. An

individual’s gender is not immediately apparent. And normally there would be too many identical first names –

a phenomenon called “name collision” – to make UserID’s based on first names practical.

The best UserID’s for Confidentiality purposes are those with no relationship to their bearer at all, and this

is recommended. A UserID of “N123456” reveals nothing about the user or the organization.

Many organizations

eschew

such

UserIDs

as

being

TOO

anonymous

or

dehumanizing,

and

insist

on

using

name‐based UserIDs. This is often an element of organizational culture, and in a particular enterprise a UserID

of the form “Aander01” may be acceptably personal.

The confidentiality of such an account is fairly simple. There is usually no Secrecy threat to the enterprise

unless employment is for some reason secret, in which case such UserIDs are very unlikely. The Privacy threat

is minimized by the use of only the first initial and last name. Notably different from badges, one’s gender is

not apparent in a UserID, and this format does not reveal gender. Additionally, there is no obvious connection

between a badge

holder

and

a UserID

–

seeing

the

employment

badge

of

Alice

A.

provides

minimal

clues

that

her UserID is “aander01,” and vice‐versa.

Table 7 summarizes the functions of each authentication (AuthN) tool and the associated Secrecy and

Privacy exposures. This is a simple for of Risk Analysis that we will explore later. For now, note that by

minimizing the data each AuthN tool exposes to those elements strictly necessary to meet the intended

Function we have developed configurations that minimize the risks to the enterprise to those necessary to

accomplish that function. By doing so the design minimizes the chances of associating the Badge to the UserID

to a casual observer, reducing the chance of successful phishing by someone who might read Alice’s badge in a

public setting, or see Alice’s UserID on a communication such as an e‐mail.




Table 7. AuthN summary

Function Secrecy exposure Privacy exposure

Badge

“Alice A.”

Associate real person

with code on badge

Employment Status

Department or

business

silo

Morphology (gender,

race, appearance)

First Name

Initial of Last Name

Workplace

UserID

“Aanders01”

Associate computer

identification code with

real person

None Last Name

Initial of First Name

Workplace

1 3 A p p e n d i x F . SAML R e q u e s t

The SAML Aut hent i cat i onSt at ement contains data from a “SAML authority” – a server that is trusted

to provide authentication – concerning a person or service or device whose identity is in question here, called

the “subject.” The authentication statement includes

information describing how the assertion is bound to the

subject. In this case, it is Holder of Key , indicating that the

message carries a public key. Assuming we trust the SAML

authority, we can be confident that anything we receive that

is signed

with

the

corresponding

private

key

came

from

the

subject.

Immediately after the Aut hent i cat i onSt at ement is a

Si gnat ure binding the Asser t i on to the issuing SAML

authority so that we can verify the message has come from a

trusted SAML authority.

So, now we have an assertion that contains the public key of some subject known to a SAML authority. The

next Si gnat ure element (blue in the diagram) is the signature of the SOAP Body within which the SAML

message is encapsulated. This signature binds the Body (and its payload ‐ the request that the recipient is

going to process) to the subject. This Si gnature references the earlier Asser t i on ‐ the recipient is to use the

public key in the Assert i on to verify the signature.

The recipient thus has all the pieces it needs to verify that

Figure 12. Example SAML authentication




The message was not tampered with in transit (integrity)

The body was signed by some subject identified by a SAML authority identified by an X.509 certificate.




Cases 1FA: single‐factor authentication. An authentication process that verifies elements from only one of the three

authentication categories. Asking for a password and one's mother's maiden name constitutes single‐factor

authentication because these are both "something you know."...................................................................... 10

2FA: two‐factor authentication. Authentication which verifies any two of the three authentication factors..... 10

AD: Microsoft’s implementation of LDAP ............................................................................................................. 11

ARC:

architecture

review

council,

the

formal

or

informal

body

that

approves

IT

project

implementations ....... 39

AuthN: AutheNtication ‐ the process of assuring the link between an individual and a UserID .......................... 64

AuthR: AuthoRization ‐ the process of assigning rights to an authenticated UserID (sometimes abbreviated

AuthZ) ................................................................................................................................................................ 12

BCP: business continuity planning, processes for restoring service after an outage............................................ 47

CFO: chief financial officer, the enterprise officer responsible for costs and risks............................................... 25

CFR: Code of Federal Regulation, executive rules published by the Federal Register.......................................... 42

CIA: the combination of confidentiality, integrity, and availability that represent the primary factors shaping

security ....................................................................................................................... ..........................................6

CISO: Chief Information Security Officer. The corporate officer responsible for enterprise security strategy,

planning, and risk analysis....................................................................................................................................4

CMMI: capability maturity model index, a measure of the operational maturity of process management in an

enterprise .......................................................................................................................................................... 32

COTS: common,

off

the

shelf

‐commercial

products,

the

security

of

which

is

determined

by

and

limited

to

the

built‐in configuration......................................................................................................................................... 12

DAC: discretionary access control, an authorization architecture allowing limited security management by

individual UserIDs.............................................................................................................................................. 13




DDOS: Distributed Denial of Service attack ‐ a means of reducing Availability by programming a large number of

computers to simultaneously flood a service with data in order to overwhelm it. The coordination is usually

via trojan horse programs and the data transmitted is usualy crafted to exploit a detecte vulnerability in the

service...................................................................................................................................................................9

DID: the distribution of security controls across multiple layers of the network ....................................................5

DNS: Domain Name Service, the means of mapping an IP address to a text name ............................................. 11

DPD: legal demand for the production of documents, usually at the initiation of a lawsuit................................ 54

DR: disaster recovery, the processes to take place after a catastrophic failure................................................... 60

DSS: Data Security Standards required by PCI ...................................................................................................... 35

EISP: Enterprise Information Security Program. The collection of policies, processes, standards and training that

establish and maintain security operations and awareness ................................................................................4

Enterprise: a generic term referring to almost any kind of organization.................................................................4

EPHI: electronic protected health information, as defined by HIPAA legislation ....................................................6

ESI: legal term for any electronically stored information ..................................................................................... 54

FBI: Federal Bureau of Investigation ........................................................................................................................4

FDA: Food and Drug Administration, part of the US Department of Health and Human Services, concerned with

information security regarding the manufacture of drugs ............................................................................... 42

FISMA: 2002 federal legislation focused on information security ........................................................................ 49

FOIA: a Freedom Of Information Act request is a formal request to the US Federal government for the release

of information in a specific case or about a specific individual............................................................................7

FTP: File transfer protocol, a dreadfully ancient and insecure means of moving files between two systems,

originally

developed

for

mainframe‐

terminal

architecture .............................................................................. 13

GLBA: Gramm‐Leach Bliley Amendment, 1999 banking industry legislation that includes some information

security rules ..................................................................................................................................................... 49

HA: high availability, a critical service that must never suffer downtime............................................................. 26

HID: host‐based intrusion detection, monitors for malware on servers and workstations.................................. 22




HIPAA: Health Information Portability and Accountability Act, a 1996 law regarding the management of

personal health information.............................................................................................................................. 33

HRSA: Heath Resources Services Administration, part of the US Department of Health and Human Services ... 33

identity: the set of facts that, when combined, serve to link a UserID to an individual across all aspects of an

enterprise .......................................................................................................................................................... 62

IdM: Identity Management ‐ the integration of all authentication and authorization processes across an

enterprise so that a given individual has appropriate rights and access at any given time ............................. 11

IDS: intrusion detection system, includes both HIDS and NIDS ............................................................................ 57

IS: Information Systems............................................................................................................................................4

ISP: Internet Service Provider...................................................................................................................................7

IT: Information Technology ......................................................................................................................................4

LDAP: Lightweight Directory Access Protocol. A simple, generic service for authenticating UserIDs .................. 11

MSSP: managed security service providers, outsourced third party security firms ............................................. 52

NID: network based intrusion detection, watches for malware on communications channels ........................... 26

NIST: National Institute of Standards and Technology, part of the US Department of Commerce...................... 33

OWASP: Open Web Application security Project, a nonprofit organization dedicated to increasing the security

of software development.................................................................................................................................. 42

PCI: payment card industry, an alliance of credit card organizations dedicated to improving security of credit

card data............................................................................................................................................................ 30

Phishing: classic 'confidence games' carried out over modern electronic communications media, this usually

involves masquerading as a trusted party in order to violate the secrecy or privacy of a target..................... 63

platform: The

combination

of

server

hardware

with

operating

system

software

selected

by

an

enterprise

as

a

standard server architecture............................................................................................................................. 11

QSA: qualified security assessors, certified by PCI to audit against DSS ............................................................... 36

RBAC: role‐based access control, an authorization architecture that places UserIDs into roles defined by

business requirements ...................................................................................................................................... 14




RM: the practice of identifying, classifying, archiving, preserving and destroying records.................................. 44

SAML: Security Assertion Markup Language, a means of abstracting security protocols using XML................... 12

SDLC: software

development

life

cycle,

the

procedure

for

initiating,

creating,

maintaining

and

concluding

software in an enterprise .................................................................................................................................. 19

SLA: service level agreement, the contracted availability of a service ................................................................. 49

SLO: single log‐on, the use of the same password across different UserIDs on different platforms ................... 11

SOAP: formerly Simple Object Access Protocol, SOAP was divorced from this meaning and became its

standalone name in 2003. .......................................................................................................................... ....... 12

SoD: separation or segregation of duties, a means of fraud prevention that demands two individuals co‐operate

in carrying out privileged functions................................................................................................................... 15

SOX: Sarbanes Oxley Amendment, a 2002 law focused on the banking industry and including some security

management rules............................................................................................................................................. 31

SSO: single sign‐on, the ability to authenticate once and thereafter access all authorized systems ................... 12

STAR: security tracking and risk forms that document the security of an enterprise element across its lifetime38

STRIDE: spoofing, tampering, repudiation, information disclosure, denial of service, elevation of privilege, areas

of possible

threats ............................................................................................................................................. 48

TSA: Transportation Security Authority ‐ the security theater branch of the Department of Homeland Security .6

USB: Universal Serial Bus, a technology for seamlessly attaching devices such as storage media to a computer..4

UserID: User identifier ‐ a sequence of letters and numbers used as an index for a table of identities of

authorized system users.......................................................................................................................................9

XML: eXtensible Markup Language ‐ a text based protocol for abstracting protocol and software components

away

from

their

underlying

technologies,

allowing

for

the

creation

of

languages

and

protocols

not

limited

to

a particular technology base ............................................................................................................................. 12




1 4 B i b l i o g r a p h y

(ISC)2. (2005). Securing the Organization: Creating a Partnership Between HR and Information Security.

Retrieved Oct 31, 2011, from ISC2.org:

https://www.isc2.org/uploadedfiles/industry_resources/hrwhitepaper.pdf

Anderson, J. P. (1972, October). Computer Security Technology Planning Study. ESD‐TR‐73‐51, ESD/AFSC,

Hanscom AFB, Bedford, MA [NTIS AD‐758 206], II, 58.

Bell, D. E., & LaPadula, L. J. (1973). Secure Computer Systems: Mathematical Foundations. MITRE Corporation.

Biba, K. J. (1977). Integrity Considerations for Secure Computer Systems. The MITRE Corporation. Bedford,

Mass: ESD‐TR‐76‐372, ESD/AFSC, Hanscom AFB.

Bilton, N.

(2011,

May

3).

How

Credit

Card

Data

is

Stolen

and

Sold.

Retrieved

Oct

31,

2011,

from

The

New

York

Times: http://bits.blogs.nytimes.com/2011/05/03/card‐data‐is‐stolen‐and‐sold/

Boni, W. (2011, Oct 10). EISP Interview. (R. Alberti, Interviewer)

Brooks, M. (2010, Mar 22). PCI Compliance – Why Merchants Need To Take It Seriously. Retrieved Oct 31,

2011, from Transactions Management and Compliance: http://www.tmspay.com/2010/03/22/pci‐

compliance‐why‐merchants‐need‐to‐take‐it‐seriously‐part‐i/

Burke, W. (2002). Organizational Change: Theory and Practice. London: Sage Publications, Ltd.

Carnegie Mellon Software Engineering Institute. (2000). Models of Information Security Analysis. Retrieved Oct

31, 2011, from CERT Centers: http://www.cert.org/

Carnegie Mellon

Software

Engineering

Institute.

(2011).

Capability

Maturity

Model

Integration.

Retrieved

Oct

31, 2011, from Carnegie Mellon University: http://www.sei.cmu.edu/cmmi/

Connolly, C. (2008). Safe Harbor: Fact or Fiction? Pyrmont, NWS, AU: Galexia Pty, Ltd.

Cummings, M. M. (2006). Homeland Security Risk Assessment. Arlington, VA: Homeland Security Institute

Analytic Services, Inc.

Data Governance Institute. (2008). California SB 1386. Retrieved October 31, 2011, from Datagovernance.com:

http://www.datagovernance.com/adl_data_laws_california_security_breach_notifi.html

Deibert, R. & Rohozinski, R. (2009). Tracking Ghostnet: Investigating a Cyber‐Espionage Network. University of

Toronto at Trinity College, Munk Center for International Studies. Toronto: The SecDev Group.

Deloitte.

(April,

2005).

Calling

an

Change

in

the

Outsourcing

Market.

Deloit

Development

LLC.

DHS HIPAA Program Management Office. (2002, March 21). Guidance for Identifying Business Associates.

Retrieved October 31, 2011, from North Carolina Department of Health and Human Services:

http://info.dhhs.state.nc.us/olm/manuals/dhs/pol‐

80/man/guidance_for_identifying_business_associates.pdf

Electronic Freedom Foundation. (2011, April 1). Documents Obtained by EFF Reveal FBI Patriot Act Abuses.

Retrieved October 31, 2011, from https://www.eff.org/deeplinks/2011/03/documents‐obtained‐eff ‐

reveal‐fbi‐patriot‐act




Electronic Privacy Information Center. (2001, May 24). USA Patriot Act (HR 3162). Retrieved October 31, 2011,

from epic.org: http://epic.org/privacy/terrorism/hr3162.html

Europa Summaries of EU Legislation. (2011, Feb 01). Protection of Personal Data. Retrieved Oct 31, 2011, from

Europa.eu: http://europa.eu/legislation_summaries/information_society/data_protection/l14012_en.htm

Federal Drug Administration. (2000, June 27). Policies and Practices for Storing, Retrieving, Accessing, and

Disposing of Records in the System. Federal Register, 65(124), 39623‐39624.

Federal Financial Institutions Examination Council. (2005, October 12). Authentication in an Internet Banking

Environment. Retrieved October 31, 2011, from FFIEC.GOV:

http://www.ffiec.gov/pdf/authentication_guidance.pdf

Federal Financial Institutions Examination Council. (2006, August 15). Frequently Asked Questions on FFIEC

Guidance on Authentication in an Internet Banking Environment. Retrieved October 31, 2011, from

FFIEC.GOV: http://www.ffiec.gov/pdf/authentication_faq.pdf

Federal Rules of Civil Procedure. (2011). Cornell University Law School. Retrieved October 31, 2011, from Legal

Information Institute:

http://www.law.cornell.edu/rules/frcp/Rule30.htm

Ferraiolo, D., & Kuhn, R. (1995, December). An Introduction to Role‐Based Access Control. NIST/ITL Bulletin.

French, P. (2004, January). Electronic Document Retention Policies. Retrieved October 31, 2011, from

http://apps.americanbar.org/lpm/lpt/articles/ftr01045.html

Gaudin, S. (2002, September 25). From Cost Center to Profit Center. Retrieved Oct 15, 2011, from Datamation:

http://www.datamation.com/netsys/article.php/1470461/From‐Cost‐Center‐To‐Profit‐Center‐The‐IT‐

Evolution.htm

Gladwell, M. (2000). The Tipping Point. New York: Little, Brown and Company.

Glasspath. (2001, April 14). Glasspath Security. Retrieved October 31, 2011, from the Internet Archive:

http://web.archive.org/web/20010708145540/http://www.glasspath.com/default_1.asp?Page=Security

Goldberg, J. (2008, November). The Things He Carried. Retrieved October 31, 2011, from The Atlantic:

http://www.theatlantic.com/magazine/archive/2008/11/the‐things‐he‐carried/7057/

Gollmann, D. (1999). Computer Security. Chichester, UK: John Wiley & Sons Ltd.

Hahn, R., & Layne‐Farrar, A. (2006). The Law and Economics of Software Security. Harvard Journal of Law and

Public Policy, 30(1), 284‐351.

Hall, E. (1998). Managing Risk; Methods for Software Systems Development. New York: Addison‐Wesley.

Harwood, M. (2011). Security Strategies in Web Applications and Social Networking. Sudbury, MA: Jones &

Bartlett.

Henderson, G.

(2011,

Sept

16).

Privacy

Alert:

Google

Now

Allows

Opt

‐Out

for

Location

Data.

Retrieved

Oct

31,

2011, from Techsling.com: http://www.techsling.com/2011/09/privacy‐alert‐google‐now‐allows‐opt‐out‐

for‐location‐data/

Hernan, S., Lambert, S., Ostwald, T., & Shostack, A. (2006, Nov). Uncover Security Design Flaws Using The

STRIDE Approach. Retrieved October 31, 2011, from MSDN Magazine: http://msdn.microsoft.com/en‐

us/magazine/cc163519.aspx

International Charter. (2005, Feb). The Risk Equation. Retrieved Oct 31, 2011, from The International Charter:

http://www.icharter.org/articles/risk_equation.html




Jaeger, T. (2008). Operating System Security. San Antonio: Morgan & Claypool.

Jones, J. (2005). Introduction to Factor Analysis of Information Risk. Retrieved Oct 31, 2011, from Risk

Management Insight: www.riskmanagementinsight.com/media/docs/FAIR_introduction.pdf

Karyda, M.,

&

Mitrou,

E.

(2006).

A

Framework

for

Outsourcing

IS/IT

security

services.

Information

Management

& Computer Security, 402‐415.

Kerckhoffs, A. (1883, Jan). La cryptographie militaire. Journal des sciences militaires, IX, 5‐83.

Kobrin, S. J. (2004). Safe harbours are hard to find: the trans‐Atlantic data privacy dispute, territorial

jurisdiction and global governance. Review of International Studies, 30, 111‐131.

Krup, N., & Movius, L. (2009). U.S. and EU Privacy Policy: Comparison of Regulatory Approaches. International

Journal of Communication, 3, 169‐187.

Leavitt, J. (2007, June). Designing a Compliant Electronic Record‐Retention Policy. Association Law & Policy,

14(11).

Lee, D.

(2011,

Dec

1).

PwC

Reports

Increase

in

Fraud,

Cyber

Crime.

Retrieved

Dec

11,

2011,

from

Insurance

Networking: http://www.insurancenetworking.com/news/cyber‐crime‐fraud‐it‐risk‐29436‐1.html

Lewin, K. (1944). A Research Approach to Leadership Problems. Journal of Educational Sociology, 17(7), 392‐

398.

Lyon, D. (2001). Surveillance Society. (T. May, Ed.) Buckingham, United Kingdom: Open University Press.

Maschak, P. (2003, June 22). Change Control Process for Firewalls. Retrieved Oct 31, 2011, from SANS Infosec

Reading Room: http://www.sans.org/reading_room/whitepapers/basics/change‐control‐process‐

firewalls_1131

Mehalko, M., & Pulliam, L. (2011, Oct 31). SEC Issues Guidelines on Cyber Attack Reporting. Retrieved Oct 31,

2011, from Benesch Law Cyber Security: http://www.beneschlaw.com/cyber‐security‐sec‐issues‐

guidelines‐on

‐cyber

‐attack

‐reporting

‐10

‐31

‐2011/

Monroe, R. (2011, Aug 10). Password Strength. Retrieved Oct 31, 2011, from XKCD: http://xkcd.com/936

National Conference of State Legislatures. (2010, October 12 ). State Security Breach Notification Laws.

Retrieved October 31, 2011, from NCSL.org: http://www.ncsl.org/default.aspx?tabid=13489

National Institute of Standards and Technology. (2003, Oct). Building an Information Technology Security

Awareness and Training Program. Retrieved Oct 31, 2011, from NIST‐SP800‐50:

http://csrc.nist.gov/publications/instpubs/800‐50/NIST‐SP800‐50.pdf

Oltsik, J. (2011, Mar 31). To Whom Should the CISO Report? Retrieved Oct 31, 2011, from Network World:

http://www.networkworld.com/community/whom‐should‐ciso‐report

Ponemon, L.

(2010,

Apr

19).

Five

Countries:

Cost

of

Data

Breech.

Retrieved

Oct

31,

2011,

from

The

Ponemon

Institute:

http://www.ponemon.org/local/upload/fckjail/generalcontent/18/file/2010%20Global%20CODB.pdf

Rodriguez, S. (2011, Jul 5). Attacks on websites spark demand for cyber‐security experts. Retrieved Oct 31,

2011, from Los Angeles Times: http://articles.latimes.com/2011/jul/05/business/la‐fi‐hacking‐security‐

20110705

Sandhu, R. (1990, September). Separation of duties in computerized information systems. Proc. of the IFIP

WG11.3 Workshop on Database Security.




Sappidi, J., Curtis, B., & Szynkarski, A. (2011, Dec 8). CAST Report on Application Software Health. Retrieved Dec

8, 2011, from CAST Research: http://www.castsoftware.com/resources/resource/email‐campaigns/cast‐

report‐on‐application‐software‐health/

Schneier, B. (2003). Beyond Fear. New York: Copernicus Books.

Snow, G. (2011, Apr 12). Statement Before the Senate Judiciary Committee. Retrieved Oct 31, 2011, from

Federal Bureau of Investigation: http://www.fbi.gov/news/testimony/cybersecurity‐responding‐to‐the‐

threat‐of ‐cyber‐crime‐and‐terrorism

Stoneburner, G., Goguen, A., & Feringa, A. (2002, July). Risk Management Guide for Information Technology

Systems. Retrieved Oct 31, 2011, from NIST Special Publication 800‐30:

http://csrc.nist.gov/publications/nistpubs/800‐30/sp800‐30.pdf

Talbot, D. (2010, Apr 10). Cybercrime Needs to be Top Priority, Says Obama Aide. Retrieved Oct 31, 2011, from

Technology Review, publisher MIT: https://www.technologyreview.com/computing/25074/

Taylor, L. (2003, Jun 6). Ceritifcation and Accreditation. Retrieved Oct 31, 2011, from Intranet Journal:

http://tinyurl.com/6lsywae

Thibodeau, P. (2011, Dec 8). Java Apps Have Most Flaws, Cobol Apps the Least, Study Finds. Retrieved Dec 8,

2011, from Computer World: http://www.computerworld.com/s/article/922503/

Tipton, H., & Krause, M. (2006). Information Security Management Handbook (5 ed., Vol. 3). Boca Raton,

Florida, USA: Auerbach Publications.

Tomhave, B. (2011, Sep 26). EISP interview. (R. Alberti, Interviewer)

Umerley, R. (2011, Jun 26). Observations from the Gartner CISO Summit. Retrieved Oct 31, 2011, from SecJitsu:

The Art of Security: http://www.secjitsu.com/2011/06/25/observations‐from‐the‐gartner‐summit

Wheeler, D. (2003). Secure Programming for Linux and Unix. Retrieved Oct 31, 2011, from DWheeler.com:

http://www.dwheeler.com/secure‐programs/Secure

‐Programs

‐HOWTO/open

‐source

‐security.html

Whitmer, M. (2006, Jul). Born of Necessity: The CISO Evolution. Retrieved Oct 31, 2011, from National

Association of State CIO Officers: http://www.nascio.org/publications/NASCIO‐CIOS_Brief_071006.pdf

Xie, N. (2004, Nov). SQUARE Project: Cost/Benefit Analysis Framework for Information Security Improvement

for Small Companies. Carnegie Mellon University: Networked Systems Survivability Program .

Zetter, K. (2010, Mar 25). TJX Hacker Gets 20 Years in Prison. Retrieved Oct 31, 2011, from Wired.com:

http://www.wired.com/threatlevel/2010/03/tjx‐sentencing/