A Roadmap to Develop Enterprise Security Architecture
Maryam Tahajod1, Azadeh Iranmehr2, Arya Iranmehr3, Mohammad Reza Darajeh1
Darioon Branch1, Sama Branch2 {Shiraz Islamic Azad University}, Shiraz University3; Iran
tahajod, iranmehr, airanmehr, darajeh@{gmail.com}
Abstract
Generally speaking, there is no single solution for
security architecture in each enterprise; however,
there are common elements of security architecture
that enterprises should consider when developing their
security plan. Security services provide confidentiality,
integrity, and availability services for the platform.
This paper describes a way to map these security
services into overall enterprise security architecture.
We demonstrate a framework for understanding
disparate design and process considerations; to
organize architecture and actions toward improving
enterprise security. The security architecture roadmap
depicts an approach to map the enterprise’s goals to a
logical view for security, which is set of security policy
and standards, security architecture, and risk
management domains. The decisions in the logical
layer drive the security processes through design time
to run time.
1. Introduction
Developing an security architecture allows
organizations to identify the business, IT and
compliance elements that must be secured to achieve
key objectives and goals, and provides key
stakeholders with the ability to plan and prioritize
strategic IT security investments pertinent to
technology implementations, process enhancements
and user awareness initiatives.
In this article, we'll discuss how to create security
architecture, including analysis, planning and
prioritizing security needs. This document sets
priorities for how the enterprise can efficiently and
effectively address the management, control, and
protection of information assets. It outlines the
enterprise’s security Strategic Objectives that grouped
into three categories.
There are significant gaps between the enterprise’s
security and security Strategic Objectives. The security
architecture road map depicts an approach to fill these
gaps.
Copyright © 2009 by the Institute of Electrical and Electronics Engineers, Inc. All rights reserved.
This roadmap attempts to align information
security strategic objectives with business strategies. It
also incorporates core information security
requirements that must be in place to accomplish major
enterprise initiatives efficiently and effectively. These
initiatives include data center consolidation and the
development of major business applications.
2. Security architecture
Traditionally, security architecture is a document,
which specifies which security services are provided
how and where, in a layered model. Originally the
model typically referred to OSI layers and specified
the security elements or services and the mechanisms
used to provide them [2].
Our understanding of Security elements has
expanded to include for example Vulnerability
management, Patch management, Identity
Management and many more. In addition many
organizations do not have a Security Architecture in
the form of a single document. Security architecture is
interpreted very differently from organization to
organization.
A Security Architecture is a cohesive security
design, which addresses the requirements (e.g.
authentication, authorization, etc.) – and in particular
the risks of a particular environment/scenario, and
specifies what security controls are to be applied
where[2]. The design process should be reproducible.
How information is managed, controlled, and
protected has a significant impact on the delivery of
enterprise services and on the trust instilled in the users
of those services. Information assets, including those
held in trust, must be protected from unauthorized
disclosure, theft, loss, destruction, and alteration.
Information assets must be available when needed,
particularly during emergencies and times of crisis.
The enterprise information technology environment
is inherently difficult to secure. Most enterprises have
not defined or enforced standards limiting the diversity
of hardware and software products.
Cyber crime has skyrocketed over the past few years,
shifting from crimes of notoriety to far more serious
crimes for financial gain [1]. Attackers have become
much more sophisticated in perpetrating and
concealing cyber crimes, typically operating in stealth
mode with a goal of avoiding detection altogether [1].
The security architecture depicts an approach to
map the system’s stakeholders’ conceptual goals to a
logical view for security, which is set of security
policy and standards, security architecture, and risk
management domains [7]. Architects can learn how to
design reusable security services that make it simpler
for developers to build security into their systems.
Once security concerns are embedded in test plans and
use cases, and aligned with business goals, the overall
burden on defining demand for security services does
not solely fall on the information security team, and
the development and operations staff has far greater
organizational support for the demands of extra initial
time and expense required to build a more robust
system.
The Figure 1 illustrates the following propositions
(starting at the top-left) [8]:
Figure 1. Security Architecture dependency and
relationship
x Designing security architecture should be
a response to Business strategy and
requirements.
x The IT Strategy should be a response to
the Business strategy and requirements.
x The IT Reference Architecture(s) should
be a response to the IT Strategy and
Governance. The reference architecture
will usually address multiple platforms.
x The Reference Security Architecture(s) is
part of the IT Architecture even if it is
published as a separate document.
x IT Security Risk Management, process
and criteria. Are derived from the
Business strategy and requirements.
x A set of Baseline Controls is generated
based on the Security Policy, Directives,
and Standards etc. By Baseline Controls
we understand mandatory minimum
standards for the organization. Input
comes from the legal/regulatory
environment, Benchmarking and
published security “good practice” etc.
x Additional controls are derived from the
Risk management process.
x The security Architecture is the
embodiment of the baseline and the
additional security controls. It can also be
defined to include the policies, directives,
standards and the risk management
process.
x Some organizations use the term solution
architecture to refer to the specific
implementations derived from the
reference architecture.
The Figure 1 reflects the different interpretations of
Security Architecture identified by the members of
security working group.
3. Security Services
Security services provide confidentiality, integrity,
and availability services for the platform. Security
services are implemented as protection services, such
as authentication and authorization, detection services,
such as monitoring and auditing, and response
services, such as incident response and forensics [4].
These services have served as the goals and objectives
for information security programs for many years, but
they do not provide an actionable plan as such. This
document describes a way to map these security
services into overall enterprise security architecture.
4. Stakeholders
A client with a material stake in the systems
development and operations, including business users,
customers, legal team, and so on can be named as a
stakeholder. The stakeholders business and risk goals
drive the overall security architecture. While it may
initially appear that enterprise security does not have
many allies, there may be more than expected. The
challenge for enterprise security groups is to identify
stakeholders in the enterprise that have a stake in the
system’s security posture and to educate them about
the actual risks and available countermeasures; finally
giving the stakeholders’ their own, custom metrics,
tools and process they can bring to bear on the
problem. Architects can learn how to design reusable
security services that make it simpler for developers to
build security into their systems. Once security
concerns are embedded in test plans and use cases, and
aligned with business goals, the overall burden on
defining demand for security services does not solely
fall on the information security team, and the
development and operations staff has far greater
organizational support for the demands of extra initial
time and expense required to build a more robust
system.
5. Strategic Objectives
The high-level strategies outlined in this section
collectively define where enterprise needs to be to
appropriately manage cyber security risks [5]. The
strategic outcomes can be classified into three broad
categories:
x Improved Situational Awareness – Outcomes in
this category will help the enterprise obtain a better
understanding of its risk posture. They also will
give the state the ability to measure its risk posture
with rigorous performance metrics.
x Proactive Risk Management – Outcomes in this
category will make employees and enterprise
leaders more aware of security threats. Also, they
will garner the executive support needed for
Enterprise Security Program to thrive long-term.
Finally, they include various types of preventive
controls.
x Robust Crisis and Security Incident Management –
Outcomes in this category will help the enterprise
manage security events more efficiently and
effectively, thereby minimizing damage.
6. Security process
The Enterprise Security Office and the Information
Security Council identified certain security objectives
and specific projects as “high priority.” In general,
these are areas where our current security controls are
lax or have not been applied consistently across the
enterprise, resulting in an unacceptable level of risk. In
many cases, the security community has developed
formal projects to address pressing concerns. In others,
security projects are still in the planning stages.
This section outlines security projects that the
security community believes are high priority in a
security architecture roadmap. It is not a complete
inventory of the work being done by the security
community. Rather, it is list of key initiatives that are
planned or are currently under way to address the most
pressing risks in this roadmap.
6.1. Security Information and Event
Management
Security Information and Event Management is a
central system to provide enterprise-wide security
monitoring. It improves the ability to identify complex
cyber attacks and reduced time and cost to investigate
security incidents.
6.2. Enterprise Vulnerability and Threat
Management
The Enterprise Vulnerability and Threat
Management can be described as a central system that
provides ongoing vulnerability assessments of all
information technology assets enterprise finds and
remediate problems before they are exploited by
hackers. It creates Inventory of all technology assets.
A risk management centric approach allows the
security architecture to be agile in responding to
business needs. Risk is a function of threats exploiting
vulnerabilities against assets. The threats and
vulnerabilities may be mitigated by deploying
countermeasures. The risk management process
implements risk assessment to ensure the enterprise’s
risk exposure is in line with risk tolerance goals. This
does not mean that behavior is uniformly risk averse or
risk seeking. The system should take on the
appropriate level of risk based on business goals. The
role of the security architecture is not to steer the
business away from risk, but rather to educate their
business partners about the risks they are taking and
provide countermeasures that enable the business to
take as much risk as suits their goals.
6.3 Baseline Policies, Procedures, and
Standards
Baseline Policies, Procedures, and Standards
demonstrate enterprise security policy and standard
framework. They are clear security baselines for all
government entities and policy-based foundation to
measure results. They introduce consistent application
of security controls across the enterprise.
The security policy describes all security standards
in the system [4]. Security standards should be
prescriptive guidance for people building and
operating systems, and should be backed by reusable
services wherever practical [4]. This is very important,
it is no longer acceptable for enterprise security to
exclusively function as an arbiter; security in the
enterprise needs architecture and design advocates, and
backing at runtime. Security policy and standards are
not end goals in themselves, they need to be backed by
a governance model that ensures they are in use, and
that it is practically possible to build, deploy, and
operate systems based on their intent. In practice this
means that the security architecture must define
reusable security services that allow developers to not
be security experts yet still build a secure system.
6.4. Security Awareness for Employees
Security Awareness for Employees is ongoing and
comprehensive security awareness program for all
enterprise employees. It provides better awareness of
security threats capable of impacting enterprise
operations and also provides Common baseline of
knowledge for all employees. With Security
Awareness for Employees fewer security incidents
caused by employee mistakes
6.5. Identity and Access Management
Identity and Access Management provide
centralized and streamlined access control solution for
enterprise. Uniform and repeatable access control
processes cause better security. Providing all access
through a single user ID and password provide better
experience for users of enterprise [6]. Leveraging an
external access control solution reduce costs to
develop new systems.
6.6. Enterprise Business Continuity Program
Enterprise Business Continuity Program is ongoing
continuity program to address unanticipated
disruptions to enterprise services. By this program
recovery of critical services during a crisis become
faster and the costs through leveraging shared recovery
environment is reduced. It provides better ability to
share staff during times of crisis through adoption of a
common plan format and tools.
6.7. Enterprise Security Incident Management
Enterprise Security Incident Management is
enterprise-wide approach to record, identify, and
manage information security incidents. It provides
ability to limit damage through information sharing.
Costs are reduced through the sharing of staff and
expensive forensic investigation tools.
7. Conclusions
We present the Enterprise Security architecture
roadmap. This roadmap sets priorities for management,
control, and protection of the enterprise’s information
assets.
The strategic objectives grouped into the following
3 categories:
x Improved situational awareness, which
includes continuous system monitoring
and continuous assessment of controls
x Proactive risk management, such as
solidly articulated requirements and
ongoing security training
x Robust crisis and security incident
management, which allows critical
services to continue uninterrupted in a
crisis.
This roadmap also outlines key initiatives that have
been prioritized for delivery:
x Security Information and Event
Management: provide enterprise-wide
security monitoring
x Enterprise Vulnerability and Threat
Management: provide ongoing
vulnerability assessments of all
information technology assets
x Baseline Policies, Procedures, and
Standards: complete enterprise security
policy and standard framework
x Security Awareness for Employees:
ongoing and comprehensive security
awareness program for all state employees
x Security Awareness for Government
Leaders: annual security awareness event
for government leaders and policymakers
x Identity and Access Management:
centralized and streamlined access control
solution for state government
x Enterprise Business Continuity Program:
ongoing continuity program to address
unanticipated disruptions to government
services
x Enterprise Security Incident Management:
enterprise-wide approach to record,
identify, and manage information security
incidents
Strong executive commitment and support are
crucial to the implementation of this roadmap.
Successful implementation will ensure information is
both protected and available, and that critical services
are available when needed. Security architecture is not
a static process. You can’t “set it and forget it.”

8. References
[1] CSI/FBI Computer Crime and Security Survey, 2006
http://i.cmpnet.com/gocsi/db_area/pdfs/fbi/FBI2006.pd
f , Accessed 16 January 2009

[2] Prentice Kinser, "Enterprise Security Architecture",

2007, www.issa.-centralva.org, Accessd 20 November
2008

[3] E. H. Sibley, J. B. Michael, and R. S. Sandhu, "A case-

study of security policy for manual and automated
systems," 1991.

[4] Y. Deng, J. Wang, J. J. P. Tsai, and K. Beznosov, "An

approach for modeling and analysis of security system
architectures," IEEE Transactions on Knowledge and
Data Engineering, vol. 15, pp. 1099-1119, 2003.

[5] D. E. Bell and L. J. LaPadula, "Secure computer

system: Unified exposition and Multicsinterpretation,"
The MITRE Corporation, 1976.

[6] K. Juszczyszyn, "Verifying enterprise's mandatory

access control policies withcolouredPetri nets,"
presented at Proceedings of the Twelfth IEEE
Workshop on Enabling Technologies: Infrastructure
for Collaborative Enterprises., 2003.

[7] Enterprise Security Architecture, A Business-Driven •

Approach. Sherwood, John; Andrew Clark, David
Lynas LCS Government Corporate Library
http://www.corporatelibrary.gov.bc.ca/, Accessed 20
December 2008

[8] Anthony Thorn, Tobias Christen, Beatrice Gruber,

Roland Portman, Lukas Ruf, What is a Security
Architecture?,2008