Enterprise Cloud Security option · Enterprise Cloud Security option ... waf
Enterprise Information Security Program - Alberti
-
Upload
robert-alberti -
Category
Documents
-
view
221 -
download
0
Transcript of 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
7/27/2019 Enterprise Information Security Program - Alberti
http://slidepdf.com/reader/full/enterprise-information-security-program-alberti 2/74
Enterprise Information Security Program Design 2
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
7/27/2019 Enterprise Information Security Program - Alberti
http://slidepdf.com/reader/full/enterprise-information-security-program-alberti 3/74
Enterprise Information Security Program Design 3
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
7/27/2019 Enterprise Information Security Program - Alberti
http://slidepdf.com/reader/full/enterprise-information-security-program-alberti 4/74
Enterprise Information Security Program Design 4
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
7/27/2019 Enterprise Information Security Program - Alberti
http://slidepdf.com/reader/full/enterprise-information-security-program-alberti 5/74
Enterprise Information Security Program Design 5
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.
7/27/2019 Enterprise Information Security Program - Alberti
http://slidepdf.com/reader/full/enterprise-information-security-program-alberti 6/74
Enterprise Information Security Program Design 6
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
7/27/2019 Enterprise Information Security Program - Alberti
http://slidepdf.com/reader/full/enterprise-information-security-program-alberti 7/74
Enterprise Information Security Program Design 7
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.
7/27/2019 Enterprise Information Security Program - Alberti
http://slidepdf.com/reader/full/enterprise-information-security-program-alberti 8/74
Enterprise Information Security Program Design 8
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
7/27/2019 Enterprise Information Security Program - Alberti
http://slidepdf.com/reader/full/enterprise-information-security-program-alberti 9/74
Enterprise Information Security Program Design 9
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
7/27/2019 Enterprise Information Security Program - Alberti
http://slidepdf.com/reader/full/enterprise-information-security-program-alberti 10/74
Enterprise Information Security Program Design 10
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.
7/27/2019 Enterprise Information Security Program - Alberti
http://slidepdf.com/reader/full/enterprise-information-security-program-alberti 11/74
Enterprise Information Security Program Design 11
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.
7/27/2019 Enterprise Information Security Program - Alberti
http://slidepdf.com/reader/full/enterprise-information-security-program-alberti 12/74
Enterprise Information Security Program Design 12
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
7/27/2019 Enterprise Information Security Program - Alberti
http://slidepdf.com/reader/full/enterprise-information-security-program-alberti 13/74
Enterprise Information Security Program Design 13
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”.)
7/27/2019 Enterprise Information Security Program - Alberti
http://slidepdf.com/reader/full/enterprise-information-security-program-alberti 14/74
Enterprise Information Security Program Design 14
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.
7/27/2019 Enterprise Information Security Program - Alberti
http://slidepdf.com/reader/full/enterprise-information-security-program-alberti 15/74
Enterprise Information Security Program Design 15
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.
7/27/2019 Enterprise Information Security Program - Alberti
http://slidepdf.com/reader/full/enterprise-information-security-program-alberti 16/74
Enterprise Information Security Program Design 16
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
7/27/2019 Enterprise Information Security Program - Alberti
http://slidepdf.com/reader/full/enterprise-information-security-program-alberti 17/74
Enterprise Information Security Program Design 17
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
7/27/2019 Enterprise Information Security Program - Alberti
http://slidepdf.com/reader/full/enterprise-information-security-program-alberti 18/74
Enterprise Information Security Program Design 18
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.
7/27/2019 Enterprise Information Security Program - Alberti
http://slidepdf.com/reader/full/enterprise-information-security-program-alberti 19/74
Enterprise Information Security Program Design 19
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
7/27/2019 Enterprise Information Security Program - Alberti
http://slidepdf.com/reader/full/enterprise-information-security-program-alberti 20/74
Enterprise Information Security Program Design 20
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
7/27/2019 Enterprise Information Security Program - Alberti
http://slidepdf.com/reader/full/enterprise-information-security-program-alberti 21/74
Enterprise Information Security Program Design 21
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
7/27/2019 Enterprise Information Security Program - Alberti
http://slidepdf.com/reader/full/enterprise-information-security-program-alberti 22/74
Enterprise Information Security Program Design 22
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).
7/27/2019 Enterprise Information Security Program - Alberti
http://slidepdf.com/reader/full/enterprise-information-security-program-alberti 23/74
Enterprise Information Security Program Design 23
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
7/27/2019 Enterprise Information Security Program - Alberti
http://slidepdf.com/reader/full/enterprise-information-security-program-alberti 24/74
Enterprise Information Security Program Design 24
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,
7/27/2019 Enterprise Information Security Program - Alberti
http://slidepdf.com/reader/full/enterprise-information-security-program-alberti 25/74
Enterprise Information Security Program Design 25
“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.
7/27/2019 Enterprise Information Security Program - Alberti
http://slidepdf.com/reader/full/enterprise-information-security-program-alberti 26/74
Enterprise Information Security Program Design 26
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
7/27/2019 Enterprise Information Security Program - Alberti
http://slidepdf.com/reader/full/enterprise-information-security-program-alberti 27/74
Enterprise Information Security Program Design 27
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,
7/27/2019 Enterprise Information Security Program - Alberti
http://slidepdf.com/reader/full/enterprise-information-security-program-alberti 28/74
Enterprise Information Security Program Design 28
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.
7/27/2019 Enterprise Information Security Program - Alberti
http://slidepdf.com/reader/full/enterprise-information-security-program-alberti 29/74
Enterprise Information Security Program Design 29
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
7/27/2019 Enterprise Information Security Program - Alberti
http://slidepdf.com/reader/full/enterprise-information-security-program-alberti 30/74
Enterprise Information Security Program Design 30
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.
7/27/2019 Enterprise Information Security Program - Alberti
http://slidepdf.com/reader/full/enterprise-information-security-program-alberti 31/74
Enterprise Information Security Program Design 31
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.
7/27/2019 Enterprise Information Security Program - Alberti
http://slidepdf.com/reader/full/enterprise-information-security-program-alberti 32/74
Enterprise Information Security Program Design 32
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
7/27/2019 Enterprise Information Security Program - Alberti
http://slidepdf.com/reader/full/enterprise-information-security-program-alberti 33/74
Enterprise Information Security Program Design 33
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
7/27/2019 Enterprise Information Security Program - Alberti
http://slidepdf.com/reader/full/enterprise-information-security-program-alberti 34/74
Enterprise Information Security Program Design 34
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.
7/27/2019 Enterprise Information Security Program - Alberti
http://slidepdf.com/reader/full/enterprise-information-security-program-alberti 35/74
Enterprise Information Security Program Design 35
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/
7/27/2019 Enterprise Information Security Program - Alberti
http://slidepdf.com/reader/full/enterprise-information-security-program-alberti 36/74
Enterprise Information Security Program Design 36
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.
7/27/2019 Enterprise Information Security Program - Alberti
http://slidepdf.com/reader/full/enterprise-information-security-program-alberti 37/74
Enterprise Information Security Program Design 37
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.
7/27/2019 Enterprise Information Security Program - Alberti
http://slidepdf.com/reader/full/enterprise-information-security-program-alberti 38/74
Enterprise Information Security Program Design 38
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.
7/27/2019 Enterprise Information Security Program - Alberti
http://slidepdf.com/reader/full/enterprise-information-security-program-alberti 39/74
Enterprise Information Security Program Design 39
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.
7/27/2019 Enterprise Information Security Program - Alberti
http://slidepdf.com/reader/full/enterprise-information-security-program-alberti 40/74
Enterprise Information Security Program Design 40
# 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.
7/27/2019 Enterprise Information Security Program - Alberti
http://slidepdf.com/reader/full/enterprise-information-security-program-alberti 41/74
Enterprise Information Security Program Design 41
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.
7/27/2019 Enterprise Information Security Program - Alberti
http://slidepdf.com/reader/full/enterprise-information-security-program-alberti 42/74
Enterprise Information Security Program Design 42
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:
7/27/2019 Enterprise Information Security Program - Alberti
http://slidepdf.com/reader/full/enterprise-information-security-program-alberti 43/74
Enterprise Information Security Program Design 43
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.
7/27/2019 Enterprise Information Security Program - Alberti
http://slidepdf.com/reader/full/enterprise-information-security-program-alberti 44/74
Enterprise Information Security Program Design 44
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
7/27/2019 Enterprise Information Security Program - Alberti
http://slidepdf.com/reader/full/enterprise-information-security-program-alberti 45/74
Enterprise Information Security Program Design 45
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.
7/27/2019 Enterprise Information Security Program - Alberti
http://slidepdf.com/reader/full/enterprise-information-security-program-alberti 46/74
Enterprise Information Security Program Design 46
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,
7/27/2019 Enterprise Information Security Program - Alberti
http://slidepdf.com/reader/full/enterprise-information-security-program-alberti 47/74
Enterprise Information Security Program Design 47
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
7/27/2019 Enterprise Information Security Program - Alberti
http://slidepdf.com/reader/full/enterprise-information-security-program-alberti 48/74
Enterprise Information Security Program Design 48
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
7/27/2019 Enterprise Information Security Program - Alberti
http://slidepdf.com/reader/full/enterprise-information-security-program-alberti 49/74
Enterprise Information Security Program Design 49
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
7/27/2019 Enterprise Information Security Program - Alberti
http://slidepdf.com/reader/full/enterprise-information-security-program-alberti 50/74
Enterprise Information Security Program Design 50
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
7/27/2019 Enterprise Information Security Program - Alberti
http://slidepdf.com/reader/full/enterprise-information-security-program-alberti 51/74
Enterprise Information Security Program Design 51
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
7/27/2019 Enterprise Information Security Program - Alberti
http://slidepdf.com/reader/full/enterprise-information-security-program-alberti 52/74
Enterprise Information Security Program Design 52
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.
7/27/2019 Enterprise Information Security Program - Alberti
http://slidepdf.com/reader/full/enterprise-information-security-program-alberti 53/74
Enterprise Information Security Program Design 53
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.
7/27/2019 Enterprise Information Security Program - Alberti
http://slidepdf.com/reader/full/enterprise-information-security-program-alberti 54/74
Enterprise Information Security Program Design 54
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
7/27/2019 Enterprise Information Security Program - Alberti
http://slidepdf.com/reader/full/enterprise-information-security-program-alberti 55/74
Enterprise Information Security Program Design 55
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
7/27/2019 Enterprise Information Security Program - Alberti
http://slidepdf.com/reader/full/enterprise-information-security-program-alberti 56/74
Enterprise Information Security Program Design 56
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.
7/27/2019 Enterprise Information Security Program - Alberti
http://slidepdf.com/reader/full/enterprise-information-security-program-alberti 57/74
Enterprise Information Security Program Design 57
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
7/27/2019 Enterprise Information Security Program - Alberti
http://slidepdf.com/reader/full/enterprise-information-security-program-alberti 58/74
Enterprise Information Security Program Design 58
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.
7/27/2019 Enterprise Information Security Program - Alberti
http://slidepdf.com/reader/full/enterprise-information-security-program-alberti 59/74
Enterprise Information Security Program Design 59
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.
7/27/2019 Enterprise Information Security Program - Alberti
http://slidepdf.com/reader/full/enterprise-information-security-program-alberti 60/74
Enterprise Information Security Program Design 60
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
7/27/2019 Enterprise Information Security Program - Alberti
http://slidepdf.com/reader/full/enterprise-information-security-program-alberti 61/74
Enterprise Information Security Program Design 61
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
7/27/2019 Enterprise Information Security Program - Alberti
http://slidepdf.com/reader/full/enterprise-information-security-program-alberti 62/74
Enterprise Information Security Program Design 62
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
7/27/2019 Enterprise Information Security Program - Alberti
http://slidepdf.com/reader/full/enterprise-information-security-program-alberti 63/74
Enterprise Information Security Program Design 63
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
7/27/2019 Enterprise Information Security Program - Alberti
http://slidepdf.com/reader/full/enterprise-information-security-program-alberti 64/74
Enterprise Information Security Program Design 64
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.
7/27/2019 Enterprise Information Security Program - Alberti
http://slidepdf.com/reader/full/enterprise-information-security-program-alberti 65/74
Enterprise Information Security Program Design 65
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
7/27/2019 Enterprise Information Security Program - Alberti
http://slidepdf.com/reader/full/enterprise-information-security-program-alberti 66/74
Enterprise Information Security Program Design 66
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.
7/27/2019 Enterprise Information Security Program - Alberti
http://slidepdf.com/reader/full/enterprise-information-security-program-alberti 67/74
Enterprise Information Security Program Design 67
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
7/27/2019 Enterprise Information Security Program - Alberti
http://slidepdf.com/reader/full/enterprise-information-security-program-alberti 68/74
Enterprise Information Security Program Design 68
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
7/27/2019 Enterprise Information Security Program - Alberti
http://slidepdf.com/reader/full/enterprise-information-security-program-alberti 69/74
Enterprise Information Security Program Design 69
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
7/27/2019 Enterprise Information Security Program - Alberti
http://slidepdf.com/reader/full/enterprise-information-security-program-alberti 70/74
Enterprise Information Security Program Design 70
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
7/27/2019 Enterprise Information Security Program - Alberti
http://slidepdf.com/reader/full/enterprise-information-security-program-alberti 71/74
Enterprise Information Security Program Design 71
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
7/27/2019 Enterprise Information Security Program - Alberti
http://slidepdf.com/reader/full/enterprise-information-security-program-alberti 72/74
Enterprise Information Security Program Design 72
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:
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
7/27/2019 Enterprise Information Security Program - Alberti
http://slidepdf.com/reader/full/enterprise-information-security-program-alberti 73/74
Enterprise Information Security Program Design 73
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.
7/27/2019 Enterprise Information Security Program - Alberti
http://slidepdf.com/reader/full/enterprise-information-security-program-alberti 74/74
Enterprise Information Security Program Design 74
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/