Download chapter 107: 'Common Models for Architecting an Enterprise Security Capability''
This chapter is excerpted from the book titled, 'Information Security Management Handbook, Sixth Edition', edited by Harold F. Tipton; Micki Krause, published by Auerbach Publications in May, 2007, ISBN 0849374952. Copyright 2007 Taylor & Francis Group LLC. For more information, please visit: www.auerbach-publications.com
Chapter Excerpt:
107.5 Enterprise Security Architecture Model
Enterprise security architecture (ESA) incorporates all aspects of security for an organization, including
leadership, strategy, organizational structure, planning, design, implementation, and operations. It
encompasses the people, processes, and technology aspects of security. Numerous models have been
developed, and those that communicate sound security practices share a common approach to enterprise
security. The ESA Model shown in Exhibit 107.6 is an open source model that this author has developed
to communicate this approach.
107.5.1 Executive Sponsorship
Organizations should elicit executive sponsorship for developing a corporate security program;
otherwise, the program leader will lack buy-in from other departments and will not have the ability
to enforce compliance with the program. A brief policy statement, typically issued in the form of a formal
corporate memo, should be presented from the highest corporate level in order to authorize the existence
of a corporatewide security program. This directive will justify development of the security program,
thus establishing the requirement to develop a security program charter.
The security program charter authorizes development of a formal security program, and delegates an
authority appropriate for the organization (e.g., the Chief Operating Officer [COO]). This executive
would then typically delegate this responsibility by creating a CSO or equivalent position. Note that
without executive sponsorship, the CSO will likely have difficulty applying and enforcing security
directives that impact other departments.
107.5.2 Security Program Strategy
The CSO then formulates a formal policy statement in response to the corporate directive. This broad
policy document will define the goals of the security program, as well as the organizational structure.
These must generally be approved by the corporate Board of Directors. In this example, the CEO has
designated that the COO is responsible for the security program, and the COO has delegated this
responsibility to a CSO. Many organizations have appropriately created a CSO position that reports
directly to the Board of Directors, which is preferable for organizations that face significant risks to their
business from security breaches.
A security program strategy is drafted to meet the business or mission needs of the
organization. The CSO drafts the overall security program strategy by aligning the organizational
approach to security with sound industry practices, and by leveraging common standards and
practices such as the ISO 17799, COBIT, Common Criteria (ISO 15408), and NIST publications
mentioned previously in this chapter. Application of the Security Governance Model can be
applied in this layer to assist in marrying an effective strategy with an appropriate
organizational structure.
In many organizations, sound practices suggest that the CSO formulate a security steering group, or
intra-organizational policy board, comprising representatives from each functional business area.
Customer Operations, Engineering, Finance, Internal Communications, HR, IT, Legal, Marketing, and
Sales are examples of departments that might be represented in this group. This steering group will
oversee most security policy development for the company in order to establish the organization's overall
approach to computer security.
107.5.3 Security Architecture Planning
Planning the architecture refers to planning that takes place within an established security organization.
Planning to execute security initiatives is an exercise in futility if executive sponsorship and security
program strategy have not been established. Planning encompasses the people, processes, and technology
aspects of security, and thus addresses policy, procedure, and technical implementation. Having
established executive sponsorship and security program strategy for the organization, one can continue
to develop the ESA.
If COBIT has been determined to be the standard to be used by the organization, then guidance
offered within the Planning and Organization domain falls primarily within this layer of the model,
and the other three COBIT domains will each be spread across the design, implementation, and
operations components of the lowest layer of this model. The model is scalable such that existing
standards can and should be used, yet sufficiently flexible that no one standard must be used.
Developing security policies is a critical component of this layer of the ESA Model. Again, selection of
one standard does not preclude the use of other well-known and accepted publications. A sample
approach to developing security policies in accordance with the guidance from NIST Special
Publication 800-14 follows.
Program-framework policies can now be drafted to establish the organization's overall approach to
computer security. This is a set of corporatewide policy statements that establish a framework for the
security program. Board-level direction is recommended for establishing most program policy
statements because these policies provide organizationwide direction on broad areas of program
implementation. This board-level direction is the fundamental function of the steering group, because
representatives of the board are included in this committee. Policy statements at this level reflect highlevel
decisions about priorities given to the protection of corporate data. Board-level direction is
recommended for acceptable use, remote access, information protection (a.k.a. data management), data
retention, special access (root level), network connection, system acquisition and implementation, and
other policies, as required. Program policy is usually broad enough that it does not require much
modification over time. Additional policies will need to be developed, and are categorized as issue
specific and system specific.
Board-level direction is also recommended for development of issue-specific policies, which address
specific issues of concern to the organization. Whereas program-framework policy is intended to address
the broad, organizationwide computer security program, issue-specific policies are developed to focus on
areas of current relevance, concern, and possible controversy to an organization. Issue-specific policies
are likely to require frequent revision as changes in technology and related factors take place. An example
of an issue-specific policy is one that addresses peer-to-peer file sharing via programs such as Kazaa
and Morpheus.
System owners, versus board-level representatives, are responsible for systems under their control, and
as such should establish system-specific policies for these systems. System-specific policies focus on
decisions taken by management to protect a particular system. Program policy and issue-specific policy
both address policies from a broad level, usually encompassing the entire organization. However, they do
not provide sufficient information or the direction, for example, to be used in establishing an access
control list or in training users on what actions are permitted. A system-specific policy fills this need. It is
much more focused because it addresses only one system.
In general, for issue-specific and system-specific policies, the issuer is a senior official. The more
global, controversial, or resource intensive the policy statement, the more senior the policy issuer
should be.
Many security policy decisions will apply only at the system level and will vary from system to system
within the same organization. While these decisions might appear to be too detailed to be policy, they can
be extremely important, with significant impacts on system usage and security. A management official
should make these types of decisions, as opposed to a technical system administrator. Technical system
administrators, however, often analyze the impacts of these decisions.
Once a policy structure is in place, the overall planning and management of the security life cycle is
maintained at this layer of the ESA Model.
Chapter 107: 'Common Models for Architecting an Enterprise Security Capability''
Visit the CRC Press website for a detailed description and to learn how to purchase this title.
TechTarget provides enterprise IT professionals with the information they need to perform their jobs - from developing strategy, to making cost-effective IT purchase decisions and managing their organizations' IT projects - with its network of technology-specific Web sites, events and magazines.
All Rights Reserved, Copyright 2000 - 2008, TechTarget | Read our Privacy Policy SearchSAP.com is a search service provided by TechTarget and is completely independent of and not affiliated with SAP AG.