SECURITY

ARCHITECTURE
NAVIGATING COMPLEXITY
 Security Architecture:
Navigating complexity
MARCH 2016

PUBLISHED BY
Information Security Forum Limited
Tel: +44 (0)20 7213 1745
Email: info@securityforum.org
Web: www.securityforum.org

PROJECT TEAM
David Moloney
Andrew Schuster
Nick Frost

REVIEW AND QUALITY ASSURANCE

Jason Creasey
Marilise de Villiers

DESIGN
Ross Mackenzie

WARNING
This document is confidential and is intended for the attention of and use by either organisations that are
Members of the Information Security Forum (ISF) or by persons who have purchased it from the ISF direct. If
you are not a Member of the ISF or have received this document in error, please destroy it or contact the ISF on
info@securityforum.org. Any storage or use of this document by organisations which are not Members of the
ISF or who have not validly acquired the report directly from the ISF is not permitted and strictly prohibited. This
document has been produced with care and to the best of our ability. However, both the Information Security
Forum and the Information Security Forum Limited accept no responsibility for any problems or incidents arising
from its use.

CLASSIFICATION
Restricted to ISF Members, ISF Service Providers and non-Members who have acquired the report from the ISF.

2 Security Architecture: Navigating complexity Information Security Forum

 CONTENTS
1 AN UNFULFILLED PROMISE?  5

2 HOW THIS REPORT HELPS 6

3 SECURITY ARCHITECTURE DEMYSTIFIED 7

Architectures provide multiple views 8
Architectures contain various elements 10
Security architectures can be based on an established framework 12
Security architectures can be adopted in a variety of ways 13
Security architects have a range of skills 14
Security architectures can develop progressively or by design 15
Security architectures can support change 16

4 LESSONS LEARNED: Unlocking the

value of security architecture17
Align security architecture to business priorities 17
Coordinate development and use of security architecture 18
Determine appropriate integration with enterprise architecture 18
Consider the organisational structure  20
Obtain the right balance of skills 21
Make security architecture understandable 21

5 SECURITY ARCHITECTURE IN PRACTICE 22

CONCLUSION27

APPENDIX A: Analysis of architectural frameworks28

APPENDIX B: Further reading32

ACKNOWLEDGEMENTS33

Information Security Forum Security Architecture: Navigating complexity 3

 Security architecture demystified
A security architecture comprises layered views of various elements.

BUSINESS
NEEDS

CONCEPTUAL VIEWS Terms and

describe security from a business Definitions
or organisational perspective
Security
Principles Services

Architectural
LOGICAL VIEWS
describe security from process,
Elements
technology and people perspectives

Reference Products
Library Catalogue
Reusable
Models
PHYSICAL VIEWS
describe IT
infrastructure

SECURITY ARRANGEMENTS

This approach for developing and using security architecture is based on ISF research and lessons learned:

STEP 1
Establish objectives

STEP 4 STEP 2
Review and revise Determine approach

STEP 3
Develop architecture

4 Security Architecture: Navigating complexity Information Security Forum

 1 2 3 4 5

1 AN UNFULFILLED
PROMISE?
Global information security spending across all market segments reached approximately
US$75 billion last year, and is projected to grow nearly 8% by 2019.1 To safeguard a return
on this investment, many organisations are turning to security architecture. But how can an
organisation determine whether security architecture would benefit them, and if so, how
do they unlock and realise its potential value?

THE PROMISE
Just as architecture provides a way for architects to convey complex information about the design and construction
of buildings, security architecture can help the design and implementation of information security solutions. Most
ISF Member organisations are using security architecture.2 Advocates claim many benefits3, including cost efficiencies,
IN 2006... capacity for change, andofaISF
improved alignment between business and IT, process refinements, enhanced Members
basis
surveyed “used a
upon which information risk management practices can be improved.
security architecture
29% in the development
“Business and IT programme objectives drive changes to security, but withoutofsecurity
new business
applications”3
architecture, these changes can be chaotic and inefficient.” 4 – Gartner

THE REALITY AS OF 2015...

of ISF Benchmark
respondents
Despite the promise, detractors claim that security architecture can take too long, cost too much, frustrate
answeredsenior
“yes”
managers, and limit flexibility and innovation. Security architecture is poorly understood by most people,
even those that do understand it, often struggle to articulate the associated benefits.
and CF.8.1.01
to question
“Has a security
77%
architecture been
The debate is muddied by a lack of clarity as to: established?”
Figure 1: Confusion regarding security architecture
– what security architecture is (see Figure 1)
– the role of security architects of organisations
Despite its do not have a
– the relationship between security architecture
and enterprise architecture
widespread
adoption...
51% clear definition
of security
– how security architecture delivers practical security architecture5
solutions and real business value.

NAVIGATING COMPLEXITY
Security architecture can help navigate the complexity inherent in today’s organisations, enabling better
protection against ever-more sophisticated threats.

To unlock and realise the value of security architecture, organisations must understand the basic concepts,
build on lessons learned by other organisations, and follow a structured approach for its development and use.

1 Gartner, “Forecast Analysis: Information Security, Worldwide”, first and third quarter 2015 update, http://www.gartner.com/newsroom/id/3135617
2 As of the end of December 2015, 77% of ISF Benchmark respondents had answered “yes” to the question “Has a security architecture been established."
3 Tamm et al., “How does enterprise architecture add value to organisations?” Communications of the Association for Information Systems, 2011, Vol. 28, No. 1, p. 147.
4 Gartner, “Gartner Clarifies the Definition of the Term ‘Enterprise Architecture’”, 2008.
5 Source: ISF Member workshops and Member input packs.

Information Security Forum Security Architecture: Navigating complexity 5

 1 2 3 4 5

2 HOW THIS
REPORT HELPS
This report starts by demystifying much of the confusion that surrounds security
architecture and explores how architectures can be developed and used (Section 3).

Section 4 conveys six lessons uncovered by ISF research that can help organisations achieve
greater value from security architecture:
1 Align security architecture to business priorities.
2 Coordinate development and use of security architecture.
3 Determine appropriate integration with enterprise architecture.
4 Consider the organisational structure.
5 Obtain the right balance of skills.
6 Make security architecture understandable.

Section 5 provides an approach for developing and using security architecture that applies
the lessons learned while complementing organisations’ existing approaches.

Methodology
This report is informed by ISF research into leading organisations’ efforts to get the most value
from security architecture. The research is based on thought leadership from ISF Members and
other experts – collected on ISF Live, via interviews, and during Member workshops held in
Amsterdam, Munich, London, New York and Toronto.

Readership
This report is intended for information security professionals who work with security architecture,
enterprise architecture, or both. It will also be of use to Chief Information Security Officers (CISOs),
information technology (IT) teams, programme/project managers, business process owners and
other business representatives.

A four-page executive summary complements this report.

6 Security Architecture: Navigating complexity Information Security Forum

 1 2 3 4 5

3 SECURITY ARCHITECTURE
DEMYSTIFIED
Architecture is a practice that provides ways for people to work with highly
complex information. It enables them to work effectively with large-scale,
complex projects in a consistent, systematic and structured manner.

Security architecture can enable:

Consistency of products and Reduced cost, increased efficiency

configurations and simplification
Standardisation of hardware and software Alignment of business and IT security
Consistent functionality across different objectives
platforms Improved communication regarding
Standard user provisioning and Delivering business and security requirements
access control business Validated business requirements, translated
Integrated security controls value into security controls so people understand
across infrastructure such as: the importance, rationale and implications
Common naming conventions of different security controls

Segregation of environments with Enhanced capacity for change

different security requirements A basis for improving informal risk
Controlled information flow management practices
between environments6

Many Members view these enablers as essential for information security to be perceived as adding
business value.

“The business cases wouldn’t stand up if ten projects all procured their own
solution, hired their own people, etc. Now, when the business needs something,
we can look at the security architecture to determine which elements it needs,
and I can say ‘We have a service that does that; there’s no need for you to
design, procure or operate it.’ Then we provide it.” – ISF Member

ISF research did not uncover clear evidence that security architecture was more or less likely to benefit
organisations in different sectors; however, organisations that are more likely to benefit are those that:
– need to be fast and agile (and for example need to quickly repeat successful deployments)
– are more centralised, or, if federated, have a group-level security function with the necessary mandate
– have standardised processes and services across different business functions (e.g., recruitment,
finance, appraisal, remuneration, internal billing)
– meet compliance requirements with an established security policy framework
– have many, diverse security solutions in the products catalogue
– communicate clearly to remote information security teams.

6 ISF, “The Standard of Good Practice for Information Security”, https://www.isflive.org/community/compliance/standard-of-good-practice-for-information-security

Information Security Forum Security Architecture: Navigating complexity 7

 1 2 3 4 5

This section demystifies much of the confusion surrounding architecture in general and security
architecture in particular. It describes how security architectures:
– provide multiple, different views of relevant information
– contain various elements
– are often based on an established framework
– can be adopted in a variety of ways
– are developed by people with a range of skills
– can develop progressively or by design
– can support change.

1| Architectures provide multiple views

Many cities have complex metro systems, and provide travellers with maps (views) for planning
journeys. These maps are neither to scale nor geographically accurate; however, they are concise
and show everything travellers need to plan their journeys: routes, stops and interchanges.

Figure 2: Subway maps are examples of architectural views

A vast amount of information underlies the system, yet is not relevant to travellers so is excluded from
the maps. This other information is essential to other groups, such as engineers who perform network
maintenance, and is made available to them via other views. There is no single view of a complex
project; there is a set of multiple views.

Likewise, security architecture provides multiple, simplified views of complex information, such
as security solutions or services, with each view emphasising some aspects while hiding others.7
Architectural views can link business needs to security processes, technologies and people, and can
simplify decision-making. Views are covered in more detail on the next page, and in Appendix A as
part of an explanation of architectural frameworks such as TOGAF and SABSA. They are also described
in the previous ISF report Security Architecture: Workshop Report.

7 The ISF defines security architecture as “a set of representations that describe the function, structure and interrelationship of the security components within
an environment.” Source: ISF, “Security Architecture: Workshop Report”, 2006, p. 6, https://www.isflive.org/docs/DOC-1285

8 Security Architecture: Navigating complexity Information Security Forum

 1 2 3 4 5

In addition to emphasising some aspects while hiding others, different types of architectural views can be
layered, as shown below. This allows abstract concepts to be translated into tangible change, such as the
implementation of security arrangements to meet business needs.

Figure 3: Types of views layered in a simple security architecture

BUSINESS
NEEDS EXAMPLE: ISF Live, PINsafe

Are suitable for non-technical

OBJECTIVES:
audiences – Standardise encryption techniques
– Secure remote access

Convey overall concepts – Share credentials across apps

CONCEPTUAL VIEWS
Support modelling of various
describe security from a business
or organisational perspective approaches

User name
User
mapping
Are suitable for business
process owners
Can illustrate how information One-time code

LOGICAL VIEWS moves and changes Pinsafe

describe security from process,

technology and people perspectives Can show how security
controls protect information
Authenticate

Are suitable for subject

matter experts My pin is: 1269

Are technically accurate

PHYSICAL VIEWS
B K P I

describe IT Enable implementation

infrastructure of components
B K P I

SECURITY
ARRANGEMENTS

“The end result of using a security architecture is an implementation.” – ISF Member

During the development of a security architecture, several different views are produced. The views become
less abstract and more detailed as they translate business requirements into security controls. In practice,
organisations start with a few views, and add more over time as their knowledge and experience improve.

“Use a smaller number of views that everybody understands, rather than a

comprehensive set that nobody understands.” – ISF Member

Information Security Forum Security Architecture: Navigating complexity 9

 1 2 3 4 5

2| Architectures contain various elements

Architectures capture real-world properties of a complex system. Examples include:
– load-bearing structures, floorplans and wiring diagrams of a skyscraper
– routes, signalling systems and maintenance procedures of a subway system
– data flow diagrams for a business process
– network diagrams and standard server configurations of an IT infrastructure.

They use conceptual or abstract means (such as Figure 4: The six elements of security architecture
drawings, words and diagrams) to represent those real-
world properties clearly, using multiple views. This clarity
enables complexity to be understood by multiple, diverse Terms and
Definitions
audiences. Security
Principles Services
The precise way in which security architecture accomplishes
this varies. Different architectural frameworks use different
representations and terminology. To add clarity, the ISF Architectural
has distilled the essence of different frameworks into Elements
six architectural elements (see Figure 4).

“To be successful, security architects must be Reference

Library
Products
Catalogue
able to think analytically and abstractly.” Reusable
Models
– ISF Member

The table below lists six elements that can make up a security architecture, and provides information security
examples for each.
ELEMENT EXAMPLES
PRINCIPLES: overarching concepts used The ISF Standard of Good Practice for Information Security
to improve information security (The Standard) states that:
Principles are often captured in standards, “Security architecture principles should be applied when developing
policy documents and contracts and implementing security controls, and include:
Principles should be followed when: – secure by design
– defence in depth
– developing the architecture
– secure by default
– reviewing/approving IT projects – default deny
– implementing security controls – fail secure
– secure in deployment
– usability and manageability”
These principles are described in more detail on page 13

TERMS AND DEFINITIONS: words and Using a common language can provide a clearer translation of business
phrases used to describe the structure requirements into system specifications and security controls
and content of a security architecture Examples include:
These are generally recorded in glossaries or – business process maps, data flow diagrams
taxonomies, embedded within the clauses – network diagrams, topography
of information security plans and contracts – stating likelihood and business impact consistently across enterprise
Common definitions help with risk, information risk, incident management, business continuity
communication, understanding and planning and audit
consistency – file naming conventions
– approaches to version control

“It is better to have a small number of elements that everyone

understands than 10 that you have to keep explaining.” – ISF Member

10 Security Architecture: Navigating complexity Information Security Forum

 1 2 3 4 5

ELEMENT EXAMPLES
SECURITY SERVICES AND Common controls decrease the cost relative to having diverse controls,
CONTROLS CATALOGUE: provide more consistent functionality, and lead to better-informed
a list of agreed approaches decisions about security mechanisms and risk management
These are generally listed in a Examples include:
document that records which – identity and access management (e.g., trust management,
are approved and how they are credentials management, roles and entitlement management)
to be implemented – managed security services (e.g., firewalls, other gateways,
content filtering)
– security monitoring
– security intelligence
– mobile device management (MDM) solutions
– integrated event logging and monitoring solutions
(e.g., via a SIEM and/or a SOC)

REFERENCE LIBRARY: guidance Reference libraries often include external and internal standards,
used to standardise the planning, lessons learned and major decisions
design and implementation of Examples include:
information security services – The Standard
and controls – IRAM2 (Common Threat List, Threat Event Catalogue)
– Information Risk Register
– ISO 27004
– COBIT
– ITIL

REUSABLE MODELS, Repeatable approaches to common problems (such as reusable designs

TEMPLATES OR PATTERNS:8 or configurations) lead to faster and more consistent implementation
proven approaches or Examples include:
configurations that can be – standard desktop configurations
used as designs9 – incident management and response processes
These are often captured in a – system development processes
repository which can be shared – a security component or mobile device checklist
with teams across the organisation, – common VPN protocols
such as a configuration – approved encryption techniques
management database (CMDB) – application programming interfaces (APIs)
– reusable code
– access control mechanisms, such as two-factor authentication

PRODUCTS CATALOGUE: Examples include:

approved hardware and software – vulnerability management and threat protection products
that are to be used as part of a
– information classification labelling and protection products
standard configuration
– an approved applications library, such as for mobile apps
These are generally listed in a
document that records which – firewalls
are approved, including version – malware protection solutions.
numbers, i.e., a catalogue

A given project is unlikely to use every element in a security architecture; elements can be mixed and
matched to suit specific business requirements. A security architecture can be more than a collection of
elements; it can also provide a structured methodology for developing, using and organising elements.

8 Santiago, M. G. et al. “Enterprise Security Pattern: A model-driven architecture instance”, Computer Standards & Interfaces, 2013, Vol. 23, pp. 748-758.
9 TOGAF 9.1 patterns can tell you how, when and why you design standards, and what trade-offs you have to make in doing so.

Information Security Forum Security Architecture: Navigating complexity 11

 1 2 3 4 5

3| Security architectures can be

based on an established framework
When the concept of architecture is applied to organisations, it is known as enterprise architecture. Just as
architectural blueprints help with the design and construction of complex buildings, an enterprise architecture is a
“conceptual blueprint that defines the structure and operation of an organisation.”10 An enterprise architecture can
visually represent and help navigate complexity, such as a business process or an IT estate. By doing so, enterprise
architecture supports business planning and transformation.

A number of established frameworks provide a reference structure for developing and using enterprise architecture
and security architecture. Most ISF Members develop their security architecture using one of three frameworks:

– The Open Group Architecture Framework (TOGAF®) is Figure 5: Established frameworks used to develop and
a widely adopted enterprise architecture for business
manage security architecture
planning and IT transformation. While it is not specific to TOGAF
information security, many organisations have used its
open structure to develop their security architecture. Other
58%

14%
– The SABSA® Framework11 is a framework specifically
designed for developing “business-driven, risk and
opportunity focused security architectures” that enables Established
all other existing standards to be integrated within a
Zachman
10% frameworks
single framework.12

– The Zachman Framework is one of the earliest security

frameworks, introduced by John Zachman in his 1987 18%
paper A framework for information systems architecture.13 SABSA

Some organisations develop architectures without a framework, and at least one, the US Federal Government,
has developed its own framework, the Federal Enterprise Architecture Framework,14 which has been adapted
to include information security.
NOTES: Many organisations blend aspects of different frameworks into a security architecture that meets their needs.
TOGAF and SABSA are independent frameworks; however, efforts are underway to determine
how the two might best complement each other.15
Appendix A provides additional information on TOGAF, SABSA and Zachman, including Members’ views
of the pros and cons. It also provides a list of other architectural frameworks such as the Common Data
Security Architecture (CDSA) and the Gartner Enterprise Security Architecture.

Whereas the simple security architecture shown in Figure 3 has three types of views, the SABSA framework
has six types, as shown in Figure 6.

Figure 6: Views in the SABSA Framework

CONTEXTUAL Business wisdom and decision-making

CONCEPTUAL Business attributes and risk objectives SERVICE
LOGICAL Information, services, processes, applications MANAGEMENT
PHYSICAL Data mechanisms, infrastructure, platforms Activities and processes
COMPONENT Products, tools, specific standards, technologies

10 http://searchcio.techtarget.com/definition/enterprise-architecture
11 SABSA was previously known as the Sherwood Applied Business Security Architecture.
12 The SABSA Institute, http://www.sabsa.org/
13 Zachman, J.A., “A framework for information systems architecture”, IBM Systems Journal, 1987, Vol. 26, No. 3.
14 For details, see https://www.whitehouse.gov/omb/e-gov/fea/
15 The Open Group, “How SABSA and TOGAF complement each other to create better architectures”, 2011, available at
https://www2.opengroup.org/ogsys/jsp/publications/PublicationDetails.jsp?publicationid=12449

12 Security Architecture: Navigating complexity Information Security Forum

 1 2 3 4 5

4| Security architectures can

be adopted in a variety of ways
Security architecture is not an all-or-nothing proposition. Some organisations will benefit from picking and
choosing certain elements of a security architecture – such as adopting a set of standardised products for
securing a new line of business, or by providing security criteria that need to be met by systems being developed.
Others will develop security architecture across the organisation that is aligned with their enterprise architecture.
Figure 7 provides indicative examples to show the range of possibilities.

Figure 7: Examples of varying ways organisations can adopt security architecture

An organisation may...
have a security architecture that is
use a few architectural have a security architecture have a security architecture used across the organisation and
elements from time to that is regularly used on that is used on most projects may be aligned with an enterprise
time on individual projects individual projects across the organisation architecture

Ad hoc Adoption of security architecture Structured

To illustrate the variety of ways Members are adopting security architecture, consider principles, the first of the
six architectural elements. Figure 8 shows the percentage of ISF Benchmark respondents that have applied each
principle when developing and implementing security controls.

Figure 8: Application of security architecture principles when developing and implementing security controls

ISF BENCHMARK QUESTION16 Percentage of ISF Benchmark

“Are the following security architecture principles applied when developing respondents as of December
and implementing security controls?” 2015 who answered “in most
cases” or “in all cases”

A – SECURE BY DESIGN
(i.e., considering the security requirements of a business application or information
system as part of its overall requirements, to protect itself and the information it
74%
processes, and to resist attacks)

B – DEFENCE IN DEPTH
(i.e., using multiple layers of different types of protection to avoid reliance on one 70%
type or method of security control)

C – SECURE BY DEFAULT
(i.e., setting preselected options to limit the level of inherent vulnerability, such as 74%
providing least privilege or making only necessary services and features available)

D – DEFAULT DENY
55%
(i.e., denying access to information systems by default to prevent unauthorised access)

E – FAIL SECURE
(i.e., in the event of a system failure, information is not accessible to unauthorised 70%
individuals, remains available to authorised individuals and cannot be tampered
with or modified)

F – SECURE IN DEPLOYMENT
(e.g., by providing complementary tools and guidance to help support system 49%
administrators and users, ensuring configuration is not difficult and software
updates are simple to deploy)

G – USABILITY AND MANAGEABILITY

(i.e., security controls should not obstruct users in performing their work and 54%
should not be difficult to manage)

This variation demonstrates how ISF Members are showing flexibility when applying security architecture within
their organisations.

16 This ISF Benchmark question corresponds to statement CF8.1.4 in the “ISF Standard of Good Practice for Information Security” 2013 and 2014.

Information Security Forum Security Architecture: Navigating complexity 13

 1 2 3 4 5

5| Security architects have a range of skills

Just as there is variety in how organisations adopt security architecture, there are varying levels of training, skill
and experience among the people who work with security architecture. Figure 9 provides an indicative example.

Figure 9: Examples of varying levels of experience with security architecture

An individual may...

regularly develop and use have developed a have completed some be recognised for
elements of a security security architecture professional training advanced expertise
architecture without after being trained as a security architect by earning a security
formal training on the job architecture qualification

Ad hoc Nature of experience Certified

As shown in Figure 10, the majority of respondents to an ISF survey (62%) rated their experience using a structured
approach to security architecture as “beginner” or “none”.

This is consistent with ISF Benchmark results,

Figure 10: Information security practitioners’ experience using
where half of the respondents said that the
a structured approach to security architecture
development of their security architecture
included input from internal and external security
architecture specialists. Three quarters said that
the development of their security architecture
included the education of individuals who need
to use the security architecture.

Just as security managers may be using elements

of a security architecture without actually calling
it an architecture (for example, when reviewing
IT projects from a security perspective), they
may or may not have the word “architect” in
their titles or role descriptions. On the other
hand, security managers building technical
security infrastructures based on established
designs would not meet everyone’s definition
of a security architect.

“Some people called ‘security

architects’ have little or nothing
to do with security architecture.”
– ISF Member None 12% Beginner 50% Competent 26% Expert 12%

While it may be interesting to debate whether or not an organisation has a security architecture – or whether or
not an individual is a security architect – it is largely a distraction.

Even the 23% of ISF Benchmark respondents who have not established a security architecture17 are benefitting
from architectural concepts. Almost all organisations have some of the elements that make up a security
architecture (such as standards, a system development life cycle (SDLC), version control, standard builds for
laptops, an MDM system and a service catalogue), and recognise the value these provide.

17 As of the end of December 2015, 77% of ISF Benchmark respondents had answered “yes” to the question “Has a security architecture been established?”

14 Security Architecture: Navigating complexity Information Security Forum

 1 2 3 4 5

6| Security architectures can

develop progressively or by design
Some organisations are project-focused and their security architecture builds up progressively over time.
As various projects start, the teams determine whether the project would benefit from using or developing
elements of an architecture.

“We haven’t been working on a security architecture per se, but over the last few
years, as we’ve developed systems, we’ve built patterns we can reuse. We now
have quite a catalogue.” – ISF Member
Other organisations are architecture-focused, and have a separate initiative to develop their security architecture,
often as part of a transformation programme.
The case studies below reflect two such journeys of two ISF Member organisations.

CASE STUDY 1: PROJECT-FOCUSED

A technology project helps build a security architecture over time
A division of a large financial organisation was being divested, spun off into a new company. The new company’s
executive team, focused on corporate restructuring, launched a collaborative project with the information security
team. The project would focus on enhancing controls to ensure that employees remaining with the parent
organisation could no longer gain access to the divested organisation’s infrastructure.
The team reviewed existing architectural elements (principles, reference library, models, templates and patterns)
and performed a gap analysis. They identified which elements needed to be changed or added, and developed a
short-term roadmap to improve the security architecture. As the new elements were built and incorporated into
the architecture, the impact was monitored and measured.
Once the short-term objectives were delivered, attention shifted to longer-term strategic plans for information
security. Strategic risk identification and assessment was conducted, and information security requirements
were recorded according to the ISF Standard of Good Practice for Information Security (The Standard).

CASE STUDY 2: ARCHITECTURE-FOCUSED

A business transformation programme helps build a security architecture quickly
A global business-to-consumer company was embarking on a new strategic direction in response to threats from
a radically changing competitive landscape.
An organisational risk assessment led to a transformation programme that included restructuring the business,
streamlining and automating business processes, and replacing core information systems with newer technologies
to move the business online and take advantage of social media.
The existing governance system, based on TOGAF, was used to develop a security architecture that could manage
the information security aspects of the transformation programme. Information security was viewed from a
business perspective and a model of the future state of information security was developed to respond to external
and internal business drivers (e.g., regulatory compliance and risk reduction), which highlighted new information
security principles, services and controls.
Using the security architecture, a list of information security change requirements was defined. These
requirements were categorised as immediate (i.e., part of the programme of change) and future (i.e., additional
activities to bring information security up to a higher standard).

“Security architectures contain elements of people, process, technologies and, importantly,

the culture of the enterprise in a complex and changing environment. It is important
to balance top-down direction and guidance with bottom-up pragmatism, realism
and flexibility to meet changing business needs.” – ISF Member

Information Security Forum Security Architecture: Navigating complexity 15

 1 2 3 4 5

7| Security architectures can support change

A security architecture can enable organisational change. Architectural views can help describe the current
(as is) and future (to be) states of an organisation’s security, identify gaps between the two states, and
establish a roadmap for using architectural elements to implement changes that will close the gaps.18
Gaps are closed by making changes with respect to people, information, systems, devices and infrastructure –
and changes can be applied at relevant points during corresponding life cycles.
Specific views can be developed, such as those listed in Figure 11, and then mapped to a corresponding life cycle.

Figure 11: Specific architectural views mapped to life cycles

SPECIFIC VIEW CORRESPONDING LIFE CYCLE

PEOPLE Employee engagement life cycle

INFORMATION
Information life cycle

BUSINESS APPLICATIONS
System development life cycle

PHYSICAL DEVICES

Procurement life cycle

IT INFRASTRUCTURE

Looking at the systems development life cycle, Figure 12: Use of security architecture in systems design
for example, ISF Benchmark data reveals that
over half of respondents use security architecture of ISF Benchmark
in the majority of their projects (see Figure 12). respondents
As of involve a security
Research for Application Security: Bringing order December
2015...
57% architecture in the
system design phase
to chaos found that it is 30 times more costly to fix
software errors in operations than in design. Yet,
19 in most or all cases
as shown in the table below, respondents use the
security architecture principle secure by design less frequently than they use the principle secure in deployment.

Does the system design phase involve the integration

of a security architecture that can support the technical In no In a few In half In most In all
security requirements? cases cases the cases cases cases
A – SECURE BY DESIGN 13% 13% 13% 21% 38%
F – SECURE IN DEPLOYMENT 5% 0% 20% 30% 45%

This insight shows that ISF Members may be able to reduce costs by shifting efforts from deployment to design.
Security architectures can also support change by evolving. Whereas The Standard lists seven security
architecture principles20, other principles discovered during research for this report include:
SIMPLICITY reducing the complexity and diversity of security controls leads to fewer errors, better
understanding of controls and faster resolution of issues
PARTNER UP by combining forces (e.g., specialists with non-specialists or security architects with enterprise
architects) teams can improve alignment, deliver more value and increase organisational resilience.

18 Gartner, “An Introduction to Information Security Architecture”, The Future of IT Conference, 2011, http://gartnerinfo.com/futureofit2011/MEX38L_D2%20mex38l_d2.pdf
19 ISF, Application Security: Bringing order to chaos, 2015, p. 13, https://www.isflive.org/community/process/application-security
20 Shown in this report on page 10 and described in more detail in Figure 8 on page 13.

16 Security Architecture: Navigating complexity Information Security Forum

 1 2 3 4 5

4 LESSONS LEARNED: Unlocking

the value of security architecture
The ISF researched good practice in the development and use of security architecture
using published material, Member workshops and expert interviews.

Based on the findings, the ISF uncovered six lessons for helping organisations make the most of security architecture:
1 Align security architecture to business priorities.
2 Coordinate development and use of security architecture.
3 Determine appropriate integration with enterprise architecture.
4 Consider the organisational structure.
5 Obtain the right balance of skills.
6 Make security architecture understandable.

Each of these lessons is explained below.

1| Align security architecture to business priorities

Architectures should be created to support business priorities.21

“Don’t try and make the business care about your security architecture
project, make them care about the security of their stuff.” – ISF Member

It should be clear how a security architecture is both aligned to and supports business and IT priorities,
as described in the examples below:

Potential benefits derived from the

Business priority development and use of a security architecture
Enable business transformation, For example:
innovation or growth22 – support major business and IT transformation projects
– improve scalability of security solutions
– standardise provisioning of technology
– standardise access control to business applications

Reduce costs For example:

– automate tasks and decrease human intervention
– minimise the diversity of hardware and software in use
– integrate security controls (e.g., at application, computer and network levels)
– reduce complexity of solutions, decreasing overheads

Comply with good practice, For example:

regulations or standards – improve incident detection and response
– provide consistent security functionality across different hardware
and/or software platforms
– segregate environments with different security requirements

The CISO should ensure that the business objectives of the security architecture are well-defined.

21 For more information on aligning information security strategy to business strategy, see the ISF reports “Information Security Strategy: Transitioning from alignment to integration”,
2014, https://www.isflive.org/docs/DOC-12534 and “Engaged Reporting: Fact and fortitude”, 2015, https://www.isflive.org/docs/DOC-18085
22 Obitz, T. and Babu, K.M. “Enterprise Architecture Expands Its Role in Strategic Business Transformation”, Infosys Enterprise Architecture, Infosys, 2009.

Information Security Forum Security Architecture: Navigating complexity 17

 1 2 3 4 5

2| Coordinate development and use

of security architecture
Most organisations will have multiple information security projects underway at any given time. Teams should
coordinate to determine what level of collaboration is likely to provide the most benefit. They may find that
in some cases, projects should develop views and elements of the security architecture independently, for
example when projects solve very specific issues.

In most cases, however, having project teams collaborate is a better choice, because developing views and
elements across multiple projects will:
– be more efficient, by reducing cost and saving time
– develop fewer conflicting elements, lessening confusion and improving efficiency
– ensure that new or changed views and elements are collected, retained and shared.

Working separately can be the right approach, but only if it is the result of a coordinated decision.

3| Determine appropriate integration

with enterprise architecture
In organisations that have an enterprise architecture, the security architecture may exist on its own or be
integrated with the enterprise architecture.23 Just as information security teams should coordinate with each
other when developing and using the security architecture, they should also coordinate with the enterprise
architecture team. The goal is to determine the degree to which the security architecture and enterprise
architecture should be integrated.

It may seem desirable to create a single, fully integrated architecture, because security architecture
and enterprise architecture share many common goals. ISF research found, however, that considerable
investment may be required to fully integrate the architectures, and that a single, integrated architecture
will not always be worthwhile. This is because security architectures and enterprise architectures:
– may have different business drivers and priorities
– can have different relationships to risk management and other business functions
– may have evolved separately over time
– are often based on different frameworks, use different architectural elements, models
and terminology – and need different expertise.

“There was no business case for enterprise architecture and security

architecture integration; there were just business cases for delivering
security and projects.” – ISF Member

There is work being done by The Open Group and the SABSA Institute to consider how TOGAF and SABSA
can better complement one another.24 While this initiative is underway, it’s important to note that TOGAF
and SABSA do not have to be completely independent.

23 Shariait, M., “Enterprise information security, a review of architectures and frameworks from interoperability perspective”, Procedia Computer Science, 2011, Vol. 3, p. 537.
24 The Open Group, “TOGAF and SABSA Integration: How SABSA and TOGAF complement each other to create better architectures”, 2011, available at
https://www2.opengroup.org/ogsys/jsp/publications/PublicationDetails.jsp?publicationid=12449

18 Security Architecture: Navigating complexity Information Security Forum

 1 2 3 4 5

“Having information security integrated into the enterprise architecture can help
deliver solutions efficiently without retrofitting security into projects.” – ISF Member

In some cases, security architectures that are less integrated with enterprise architectures can still be effective,
as long as both are aligned to business needs. In other cases, more integration will provide greater value.

LOOSER INTEGRATION TIGHTER INTEGRATION

is more likely to provide value when: is more likely to provide value when:
There is a wide variety of discrete business units, such The organisation is highly centralised
as in a federated enterprise structure or as a result of
many mergers and acquisitions

The security architecture supports small, isolated, The security architecture and enterprise architecture
localised or tactical projects, such as point solutions are supporting large strategic or transformation
or upgrades to products in the catalogue programmes,25 such as transformation, mergers,
and core service or product developments

The security architecture and enterprise architecture The security architecture and enterprise architecture
use different frameworks, structures, terminologies, use the same framework, structures, terminologies,
etc., and would require substantial effort to integrate etc., requiring reasonable effort to integrate

The security architecture and enterprise architecture The organisation does not have or has only just started
were developed independently and are well established developing a security architecture and an enterprise
architecture, and information security can be built
into the enterprise architecture from conception

Partial integration is also possible; for example, organisations can review their security architectures and
enterprise architectures to resolve specific conflicts.

“When our security architecture was isolated from our enterprise architecture,
the security architecture would mandate things that could not be achieved, for
example that all highly confidential data was encrypted at rest. This was not
achievable as the IT infrastructure provided by the enterprise architecture could
not accommodate such encryption.” – ISF Member
Despite a strong interest in integrating information security and enterprise architecture, few organisations
have done so. Only 21% of the Members surveyed said their security architecture was integrated into their
enterprise architecture, and over 60% did not engage with the enterprise architecture function on a regular basis.

In organisations where some integration was possible, ISF Members reported these benefits:
– reduced cost, risk and disruption
– increased business agility
– improved communications and understanding with business stakeholders due to a common language
with the enterprise architecture
– improved perception of information security from being solely a compliance or policing function to a
business enabler.

“Agility from the business is also important. Use integration to develop agility in
the business to respond to security threats, for example by allowing the business
disruption that comes from taking critical applications offline to patch critical
vulnerabilities within 24 hours of identification.” – ISF Member
25 Peristeras, V. and Tarabanis, K., “Towards an enterprise architecture for public administration using a top-down approach”, European Journal of Information Systems,
2000, Vol 9, No. 4, pp. 252-260.

Information Security Forum Security Architecture: Navigating complexity 19

 1 2 3 4 5

4| Consider the organisational structure

Organisations that have both security architecture and enterprise architecture will typically be organised in
one of two ways,26 as shown in Figure 13. In some cases, it may be worth considering which structure is most
appropriate for the organisation. If the structure is already in place, it can be useful to know the advantages
and disadvantages of each.

Figure 13: Indicative organisational structures for managing security architecture

AN ISF SURVEY FOUND THAT...

63% of Members manage their security architecture

within the information security function 37% of Members manage their security architecture
within the enterprise architecture function

CISO Head of enterprise architecture

Other information Head of security architecture Other enterprise

security roles architecture roles

Enterprise CISO
architecture team
One or more security architects, e.g. Security architects CISO is customer One or more security architects, e.g.,
infrastructure, application, network of the enterprise infrastructure, application, network
partner with enterprise
architecture team architecture team

In this structure, the security architects are part of the In this structure, the security architects and enterprise
information security function and report to the CISO. architects are part of the same team and treat the CISO
The enterprise architects work as partners. as a customer.

Each approach has its own advantages and disadvantages as outlined below:

Security architects are part of the Security architects are part of the
information security function enterprise function
ADVANTAGE The CISO can make focused decisions about There is likely to be a stronger working
information security without having to relationship between security architects
compete with other business priorities and enterprise architects
Security architects are likely to have more
direct access to knowledge and skills,
particularly business analysis skills

DISADVANTAGE The skills and expertise of the enterprise The CISO must compete with other priorities
architecture function will not be as readily for support and resources, and may struggle
available to the security architects to maintain the enterprise architecture
function’s focus on information security

“Although we started by developing our IT architecture (a part of our enterprise

architecture) separately, we eventually integrated three security principles, three
security models and 12 security standards. The main advantage was that we did
not have to sell the security architecture to the board, as it had already been sold
(and integrated) via the IT architecture.
“There are additional benefits to the IT architecture: senior leadership approval comes
more quickly when security is integrated because security is a board issue.” – ISF Member
The CISO should help to establish a governance structure that both aligns the security architecture and
enterprise architecture functions – and also clarifies which function is accountable for what architectural
views and elements, regardless of the reporting lines.27

26 Forrester Research, Job Description: Security Architect, 2014.

27 Rouhani, B.D., “A Systematic Literature Review on Enterprise Architecture Implementation Methodologies”, Information and Software Technology, 2015, Vol. 62, p.13.

20 Security Architecture: Navigating complexity Information Security Forum

 1 2 3 4 5

5| Obtain the right balance of skills

Although security practitioners do not necessarily need to be qualified security architects, a level of
competency in security architecture is required. Otherwise, security professionals may build solutions that
address a given need but cannot be reused on other projects. Likewise, without knowledge of information
security, architects could build security architectures that are academically perfect but of limited practical use.

“Security architects must have a broad set of business and technical skills –
an inch deep and a mile wide.” – ISF Member
Security architects have a broad role and often come from a technical background. Some will use security
architecture across multiple projects (for example, implementing a new cloud instance or developing
enterprise-wide identity and access management). Some will also extend the security architecture,
ensuring that projects add, change or remove views and elements.
The CREST28 syllabus for the Registered Technical Security Architect qualification29 has nine knowledge topics,
which are subdivided further into 89 specific skill areas:
KNOWLEDGE TOPICS EXAMPLE SKILL AREAS
1 Computer networking fundamentals Wireless networking, VPN, DNS, NTP
2 Virtualisation technologies Ethernet-based virtual LAN, firewalls
3 Platform security Desktop, mobile devices, databases
4 Identification and access management Directories, smart cards, biometrics
5 Cryptography PKI, storage encryption, hashing
6 Applications Thin client, web client, VoIP, SCADA
7 Governance Penetration testing, TOGAF, SDLC
8 Security methodologies Backups, attack techniques
9 Security vulnerabilities and prevention techniques Malware protection, SIEM, DLP

However, security architects may require both technical security skills and strong business acumen.30
They will need to ensure there is clear communication between relevant parties, including business units,
the security function and the enterprise architecture function if there is one.

“Security architects must be multilingual, speaking the language of business,

IT, and governance.” – ISF Member

6| Make security architecture understandable

Security architecture provides a way to manage technical complexity,31 scale and diversity. An important aspect
is enabling communication, for example by using various architectural views, consistent terms and common
reference models.
Security architects, like other subject matter experts, may use concepts and terminology unknown to those
outside of their field. Although this can aid efficiency when talking to specialists who know the jargon, it
will quickly alienate non-specialists, particularly people without a technical background. Paradoxically, this
increases rather than reduces complexity.32

“The first thing we did was identify anything with more than three syllables
and cross it out with a black pen.” – ISF Member
The onus is on security architects to avoid jargon when talking to non-architects.

28 CREST is the Council of Registered Ethical Security Testers.

29 Source: http://www.crest-approved.org/professional-qualifications/technical-security-architecture/index.html
30 Holland, R., The Security Architecture and Operations Playbook for 2015, 2015, Forrester.
31 Sherwood, J. et al., “Enterprise security architecture: A Business-Driven Approach”, 2005, CMP Media, San Francisco, p. 18.
32 Gaver, T. “Why Doesn‘t the Federal Enterprise Architecture Work?”, 2010, http://www.ech-bpm.ch/sites/default/files/articles/why_doesnt_the_federal_enterprise_architecture_work.pdf

Information Security Forum Security Architecture: Navigating complexity 21

 1 2 3 4 5

5 SECURITY ARCHITECTURE
IN PRACTICE
This section provides an approach for developing and using security architecture that is
based on ISF research and builds on the lessons described in the previous section.
As shown in Figure 14, the approach is iterative and has four steps:

Figure 14: An approach for developing and using security architecture

The approach can be used
by organisations that are
STEP 1 just starting out, by those
Establish objectives
with established security
architectures, and by
organisations in between.
STEP 4 STEP 2 It can be used in a variety
Review and revise Determine approach of ways, for example to
pick and choose particular
architectural elements, or to
STEP 3 develop an enterprise-wide
Develop architecture security architecture.

As described earlier, security architectures are comprised of:

– views: multiple, simplified ways of describing complex information (e.g., a logical view such as a network
topology or a physical view such as a data centre floor plan)
– elements: (e.g., policies, processes, services, tools, models, templates and technology catalogues33).

Developing security architecture is about creating new views and elements or updating existing ones, while
using security architecture is about taking advantage of views and elements that already exist, rather than
duplicating effort.

There are various approaches to developing and using security architecture; for simplicity, this section will
characterise two: project-focused and architecture-focused. These were covered in the case studies on page 15,
and are outlined below.
– When project-focused, teams will consider business, IT and security projects to see which can benefit from and
contribute to the security architecture, which will build up over time.
– When architecture-focused, the teams’ primary objective will be building or enhancing the architecture. Efforts
may be part of a large transformation programme, or a need, for example, to reduce the number of approved
products that perform a given function.

In practice, there may be other categories, such as the use of particular architectural elements to support day-to-
day information security. Efforts may overlap, and specifics will vary within and between organisations.

“Value is improved if the time cost of duplication of effort is minimised.” – B.D. Rouhani 34

Important: Some organisations will already have an approach to developing and using architecture, perhaps
based on an established framework (such as TOGAF, SABSA or Zachman, as described on page 12
and in Appendix A). The approach outlined in this section is provided to aid understanding, and
should not necessarily replace other approaches in use.

The four steps are described on the following pages. Each step has an overarching purpose followed by specific
activities. Hints and examples are provided to bring the activities to life.

33 Eloff, J. and Eloff, M., “Information security architecture”, Computer Fraud and Security, 2005, p.11.
34 Rouhani, B.D., “A Systematic Literature Review on Enterprise Architecture Implementation Methodologies”, Information and Software Technology, 2015, Vol. 62, p.13.

22 Security Architecture: Navigating complexity Information Security Forum

 1 2 3 4 5

STEP 1: ESTABLISH OBJECTIVES FOR SECURITY ARCHITECTURE

“Failure comes only when we forget our ideals and objectives and principles.” – Nehru

PURPOSE: Set objectives that bind the development and use of the security architecture to business
requirements,35 and be clear about the value the organisation wants to obtain from security architecture.

While different organisations, business units and projects will set different objectives to help unlock the value
they receive from security architecture, it is always important to ensure that the views and elements of the
security architecture address specific business needs.36 The table below lists the activities in this step.

ACTIVITY HINTS EXAMPLES

1.1 Analyse business context Engage with business unit Example business objectives:
Start with a clarification of both leaders, project sponsors, – implement strategic initiatives
business and IT objectives and leaders of new initiatives and
– improve efficiencies
requirements IT representatives
– reduce product and service costs
Use the language of the
business; avoid jargon – standardise compliance processes
Focus on cost efficiencies and – reduce frequency and impact of
other advantages of establishing security incidents
a more homogeneous
infrastructure

1.2 Identify how security architecture Consider whether: Example context:

is currently used – the organisation has existing – there is an agreed level of integration
Analyse the architectural context to security architecture and/or with the enterprise architecture
determine: enterprise architecture – the security architecture and enterprise
– what architectures are in use, where, – existing teams should be given architecture are based on different
by whom and for what purpose responsibility or new teams frameworks
– which frameworks they are based on should be created – team structures (see page 20) have
– how they are being used – the organisation has the been formalised
necessary capabilities (e.g., skills, – the existing technical infrastructure
– whether they are coordinated
experience, documentation and is limited
– what team structures are in place commitment)

1.3 Determine where security Consider which of the benefits Example project-focused benefit:
architecture can help (listed on page 7) could be – a new business system can use existing
If project-focused, determine: realised, or define others elements, such as an IAM (identity and
– which projects are most likely Look at the available access management) service and a
to benefit from using views and architectural information malware protection product with
elements in the security architecture (described on page 10-11) standard configuration
to see which might provide
– which projects may contribute Example architecture-focused benefits:
immediate benefit
views and elements to the security – contract consolidation
architecture
– reduced product portfolio
(As described on page 22, some projects
may be localised or tactical and less likely
to create reusable views or elements)
If architecture-focused, determine what
changes to the security architecture are
likely to provide future benefits

“Don’t be too complex and abstract when you talk architecture –

focus on business value created” – ISF Member

35 Rouhani, B.D., “A Systematic Literature Review on Enterprise Architecture Implementation Methodologies”, Information and Software Technology, 2015, Vol. 62, p.13.
36 Sherwood, J. et al., “Enterprise security architecture: A Business-Driven Approach”, 2005, CMP Media, San Francisco.

Information Security Forum Security Architecture: Navigating complexity 23

 1 2 3 4 5

STEP 2: DETERMINE APPROACH TO SECURITY ARCHITECTURE

PURPOSE: Specify the best way to achieve the objectives established in Step 1.

Based on the objectives defined in Step 1, the security architecture helps to describe current and future states
(of projects or the architecture itself) and helps to guide the organisation’s transition from one state to the other.
In this step, the onus is on the CISO and information security function to determine what architectural views and
elements can help advance security and business objectives. The table below lists the activities in this step.

ACTIVITY HINTS EXAMPLES

2.1 Describe the current state Use visual representations Example project-focused current state:
of the project or architecture of the current state – A new business system requires better
Use views and elements access control than existing elements
to aid the description can provide
Use relevant questionnaires Example architecture-focused
in the ISF Benchmark current state:
Use a maturity model37 or – The large number of diverse security
the ISF Maturity Model – solutions in the products catalogue
Accelerator Tool 38 (e.g., firewalls and intrusion detection
systems) needs to be reduced to a
manageable number

2.2 Describe the future state Use visual representations of Improved access controls (e.g., IAM
of the project or architecture the future state and how it and enhanced controls such as two-factor
compares to the current state authentication) would bring information
Use existing and proposed risk to an acceptable level
views and elements to aid
the description
Use relevant questionnaires
in the ISF Benchmark
Use a maturity model39 or
the ISF Maturity Model –
Accelerator Tool 40

2.3 Determine what to create Specify views and elements that, An evaluation of solutions needs to be
or update once created or updated, will conducted to identify the preferred options
Define the initiatives required help advance the projects and Once chosen, the new solutions will need:
to advance the future state objectives defined in Step 1
– new design and operating standards
Conduct gap analysis Engage with other information with input from business representatives,
security architects IT and security specialists
Review the existing security
architecture and identify Engage with enterprise architects – defined roles and responsibilities
which views and elements: – training for security analysts
– can help fill the gaps and – standard configurations
advance the project
– new terms and definitions (e.g., for a
– need to be changed or added SIEM, correlation, thresholds and triggers)
– process maps (e.g., for a SIEM, one that
shows how the results from the SIEM
solution support security processes)

37 ISF, Time to Grow: Using maturity models to create and protect value, 2014, https://www.isflive.org/docs/DOC-15044
38 https://www.isflive.org/docs/DOC-15042
39 ISF, Time to Grow: Using maturity models to create and protect value, 2014, https://www.isflive.org/docs/DOC-15044
40 https://www.isflive.org/docs/DOC-15042

24 Security Architecture: Navigating complexity Information Security Forum

 1 2 3 4 5

STEP 3: DEVELOP THE SECURITY ARCHITECTURE

PURPOSE: Create or update views and elements in the security architecture so that improvements in security
can be reused and are not limited to one business unit, region or project.

When projects require security changes that cannot be provided by the existing architecture, there is an opportunity
to further advance the architecture by adding, changing or removing views and elements – and doing so in a way
that benefits future projects. In this step, new architectural content is created so the organisation increases the value
of the changes to security by making them efficient and repeatable. The table below lists the activities in this step.

ACTIVITY HINTS EXAMPLES

3.1 Determine how to update Consider how these views and An implementation plan for the new
architectural content elements affect and support the solution includes time, resources and costs
Determine resource requirements, project(s) underway needed to create new architectural views
create plans and obtain necessary Consider the architectural expertise and elements and update existing ones
approvals to create and update or skills that need to be developed
views and elements

3.2 Develop new architectural Map changes to people, Preferred solutions are chosen, resulting in:
content information, business applications, – new design and operating standards being
Work with project teams to devices and IT infrastructure as part developed
create and update the views and of their respective life cycle
– roles and responsibilities being defined
elements determined in Step 2 (see Figure 11 on page 16)
– training being delivered
– standard configurations being developed
– new terms and definitions being added

3.3 Test new architectural content Select a project that is less critical The new solution is tested using vulnerability
Work with project teams to apply or in a pilot phase scans and penetration testing
new views and elements to projects Identify the teams and skill sets Changes are applied to relevant architectural
Refine content as necessary needed to adequately test the elements such as standards, policies,
new components configurations and training materials

3.4 Develop information security Identify the team who will make Training requirements are designed,
practitioner expertise and skills the changes, including any external supported by the solution provider
specialists Communications lines are established (e.g., to
Assess and develop their technical HR if the SIEM detects suspicious insider activity)
and business skills

3.5 Apply updates to security Apply version control over the The security policy is changed to cover the
architecture changes to the views and elements, new solution
Use the organisation’s change to ensure updates do not create The design and operational standards
management process to update the problems with pre-existing systems, are changed to support the implementation
security architecture (add, change processes and technologies of the new solution
or remove views and elements) Determine who should develop
and approve updates

3.6 Set targets and define measures Make benefits transparent and Measures (KPI/KRI combinations) include:
Define how security architecture measure progress at regular – results of IRAM2 risk assessment
will help the organisation intervals. Consider:
– cost reduction
Establish targets and ways to – using the ISF Benchmark Security
– quantitative operational metrics such as
measure progress against those Architecture questions to capture
IT support calls
targets over time and show progress
– qualitative operational metrics such
– consulting the ISF report Engaged
as simplified engagement between
Reporting: Fact and fortitude 41
procurement and information security
– assigning roles and responsibilities

41 The ISF report Engaged Reporting: Fact and fortitude describes how to establish relevance by engaging to understand the business context, identify common interests between
the business and information security function and develop combinations of key performance indicators and key risk indicators. https://www.isflive.org/docs/DOC-18085

Information Security Forum Security Architecture: Navigating complexity 25

 1 2 3 4 5

STEP 4: REVIEW AND REVISE

PURPOSE: Identify lessons learned and implement agreed actions for making improvements.42

In this step, the onus is on the CISO and information security function to ensure that the business’s security
requirements are being addressed and security architecture improves over time. The table below lists the
activities in this step.

ACTIVITY HINTS EXAMPLES

4.1 Measure effectiveness Consider repeating the gap Outputs show:
Use the metrics defined in 3.6 and analysis (set out in 2.3) to see if – results of IRAM2 risk assessment has
compare changes to planned targets all gaps have been addressed changed from “medium” to “low”
and achievement of the future state Apply a consistent approach to – reduced administrative overhead
measuring effectiveness
– a decrease in IT support calls
– supplier and contract consolidation
– security incident resolution times
improved

4.2 Report security improvements Report success in business terms Progress, as measured in 4.1, is
Show improvements in security translated into business terms such
as a comparison from previous as projected overall cost savings and
to current state reduced potential business impact
Socialise results to gain consensus

4.3 Share architectural content Engage security, IT and business Use of standardised elements in
with key stakeholders teams to share new views and the architecture reduce solution
Make new views and elements elements that might help them implementation time
widely available achieve their objectives
Adapt views based on business
need

4.4 Identify lessons learned from Use a workshop format to conduct The external specialist provided value
making changes to the security a review and should be involved earlier next time
architecture Discuss how lessons learned can The configuration developed for this
be applied to future security project can be applied to all customer-
projects facing systems; a different configuration
is required for internal systems

4.5 Update policy Consult the ISF Standard of Good Information security policy is updated
Modify the information security Practice for Information Security to include an additional principle
policy’s coverage of security
architecture as needed

4.6 Implement agreed actions Action plans should be assigned The scope and content of the CMDB
Create and implement action items to named individuals and include (configuration management database)
to ensure that lessons learned above measurable activities, supported is expanded
are applied and improvements are by agreed target completion The approved list of security solutions
made on a timely basis dates is amended
The IAM solution is extended to cover
cloud-based services

42 Rouhani, B.D., “A Systematic Literature Review on Enterprise Architecture Implementation Methodologies”, Information and Software Technology, 2015, Vol. 62, p.13.

26 Security Architecture: Navigating complexity Information Security Forum

 1 2 3 4 5

CONCLUSION
When appropriately deployed and well-governed, security architecture can
improve information risk management by transforming overwhelming scale,
complexity and diversity into clear representations.

The clarity provided by examining the different views of security architecture (e.g., conceptual,
logical and physical), enables organisations to selectively apply architectural elements to both
individual projects and enterprise-wide. In turn, this provides a platform that will:
– aid understanding and improve decision-making
– improve efficiency and contain cost
– support more agile and innovative business practices
– make the most of existing IT and security solutions
– realise the security objectives of the business.

Security architecture does not have to be complicated, nor fully integrated with enterprise
architecture. Many organisations are using security architecture to deliver business value
today – whether or not it’s labelled a security architecture.

This report demystifies security architecture and conveys six lessons uncovered by ISF
research. It provides a flexible approach for developing and using security architecture
that can be tailored to suit the diverse needs of organisations.

Organisations that better understand security architecture are using it to navigate the
complexity inherent in today’s interconnected world. These organisations are unlocking
value and providing a sound basis for protecting their business against ever-more
sophisticated cyber security threats.

LIVE
Join the Process community on ISF Live to share and discuss innovative approaches
for unlocking and realising value from security architecture, including:
– a discussion about the development and use of architectural elements
– developing security architecture knowledge and skills within the security function.

Information Security Forum Security Architecture: Navigating complexity 27

 APPENDIX A:
Analysis of architectural frameworks
This appendix presents additional information on the three most commonly43 used
architectural frameworks, TOGAF, SABSA and Zachman. It also includes the most common
pros and cons stated by ISF Members in workshops and Member input packs.

NOTE: The pros and cons may not apply as listed in all organisations; for example, some might argue that
a given comment is a pro rather than a con.

Further details are available at the frameworks’ websites and from other sources.

Other architectural frameworks include:

– Burton Group Reference Architecture for Security and Risk Management Strategies (SRMS)
– Cisco’s SAFE Blueprint
– Common Data Security Architecture (CDSA)
– Federal Enterprise Architecture (FEA) and Extended Enterprise Architecture Framework (E2AF)
– Gartner Enterprise Security Architecture
– Network Applications Consortium: Enterprise Security Architecture (ESA)
– Open Security Architecture
– Service-Oriented Modeling Framework (SOMF)

The Open Group Architecture Framework (TOGAF®)

TOGAF44 is a framework for developing enterprise architectures. It:
– provides methods and tools for assisting in the acceptance, production, use and maintenance of
enterprise architecture
– is based on an iterative process model supported by best practices and a reusable set of existing
architecture assets.45

TOGAF divides enterprise architecture into these categories:

1 Business architecture – the processes the business uses to meet its goals

2 Information system architecture, comprising:

– application architecture: how specific applications are designed and how they interact with each other
– data architecture: how enterprise data stores are organised and accessed

3 Technology architecture – the hardware and software infrastructure that supports applications
and their interactions

TOGAF is intended to be a framework for managing the spectrum of change required to transform an
enterprise toward its defined future (to be) operating model. This is defined by the necessary level of
business process integration and business process standardisation.

43 See Figure 5 on Page 12.

44 TOGAF 9.1, an Open Group Standard, available at: www.opengroup.org/togaf
45 The Open Group, “TOGAF and SABSA Integration: How SABSA and TOGAF complement each other to create better architectures”, 2011, available at
https://www2.opengroup.org/ogsys/jsp/publications/PublicationDetails.jsp?publicationid=12449

28 Security Architecture: Navigating complexity Information Security Forum

 Figure 15: TOGAF Content Metamodel (source: http://pubs.opengroup.org/architecture/togaf9-doc/arch/chap34.html)

Architecture principles, vision and requirements

PRELIMINARY ARCHITECTURE VISION

Architecture Business strategy Technology strategy Business principles, Architecture vision Stakeholders
principles objectives and drivers

ARCHITECTURE REQUIREMENTS
Requirements Constraints Assumptions Gaps

Business architecture Information systems architecture Technology architecture

MOTIVATION DATA APPLICATION

Platform
Drivers Goals Objectives Measures services
Data Information
ORGANISATION entities system services Logical
technology
Organisation units Locations Actors, roles Logical data Logical application components
components components
FUNCTION Physical
Business services, Physical data Physical application technology
contracts, service Processes, events, Functions components components components
qualities controls, products

Architecture realisation

OPPORTUNITIES, SOLUTIONS AND MIGRATION PLANNING IMPLEMENTATION GOVERNANCE

Work Architecture
Capabilities Standards Guidelines Specifications
packages contracts

PROS CONS
– Provides a detailed process methodology which is – Must be tailored to the needs and requirements
a well-known and utilised industry standard of an individual business; one size does not fit all
– Freely available to all organisations and individuals – Too large and cumbersome for small projects
– Includes commonly accepted enterprise architecture – Can be difficult to re-engineer existing architectures
views and terminology cost-efficiently
– Has a strong technology architecture focus – Can be seen by business stakeholders as too technical and
complicated, requiring in-depth technology experience
and skills to decipher concepts and blueprints

Information Security Forum Security Architecture: Navigating complexity 29

 The SABSA® Framework
SABSA46 is a specially developed framework for security architecture and service management. Although
developed independently from the Zachman Framework, it has a similar structure – and has evolved based
on best practice for delivering information security solutions to enterprises.
SABSA helps organisations develop “risk-driven enterprise information security and information assurance
architectures and for delivering security infrastructure solutions that support critical business initiatives”.47
It includes models, methods and processes, and its six-layer model covers a four-part life cycle:
1 Strategy and planning
2 Design
3 Implementation
4 Management and measure.
SABSA aims to ensure that the security needs of an enterprise are met based on risks and risk appetite (striving
for completeness) while being able to justify implementations in relation to business goals. The aim is to ensure
that security services are designed, delivered, and supported as an integral part of an enterprise’s IT management
(or anything in scope for the security architect).

Figure 16: SABSA Matrix (source: The SABSA Institute)

Assets (What) Motivation (Why) Process (How) People (Who) Location (Where) Time (When)
Contextual Business Business risk Business Business Business Business time
decisions processes governance geography dependence

Conceptual Business Risk Strategies Roles and Domain Time

knowledge, risk management for project responsibilities framework management
and strategy objectives assurance framework

Logical Information Risk Process maps Entity & trust Domain maps Calendar &
assets management & services framework timetable
policies

Physical Data assets Risk Process Human interface ICT infrastructure Processing
management mechanisms schedule
practices

Component ICT components Risk Process tools & Personnel Locator tools Step timing &
management standards management & standards sequencing tools
tools & standards tools & standards

Service Service delivery Operational risk Process delivery Personnel Management of Time &
management management management management management environment performance
management

PROS CONS
– Is both a structure and a methodology – Mandates that every security requirement is derived
– Focuses on making security a business enabler rather than from a specific business requirement
an obstacle and avoidable inconvenience – Considered by some Members as academic; can be
– Aims to improve understanding of business objectives difficult for many in the security field to use
– Provides a structured approach to designing a security – Can be difficult to make progress at the later stages
architecture if the business objectives, contextual and conceptual
– Seeks to align security programmes with an organisation’s architectures have not been agreed
core business activities, strategy and drivers, using existing
– May be difficult to sell if the organisation does not
architectures
understand the benefits of enterprise architecture
– Has a security focus; each layer guides security architects to
take a risk view and ensure that mitigations are considered
– Delivers a common language to show traceability and
justification of decisions

46 http://www.sabsa.org
47 J. Sherwood et al, “Enterprise Security Architecture: White Paper”, SABSA, 2009, p.1, http://www.sabsa.org/node/69

30 Security Architecture: Navigating complexity Information Security Forum

 The ZACHMAN Framework
This is an enterprise architecture framework which provides a structured approach to visualise and
articulate components in an enterprise. It has a two-dimensional classification system for describing
properties of an organisation.

It uses intersections of six fundamental questions (why, how, what, who, where and when) with a process
for successively transforming abstract ideas into concrete ones.

Figure 17: The Zachman Framework for Enterprise Architecture (source: https://www.zachman.com/about-the-zachman-framework)

Why How What Who Where When

Contextual Goal list Process list Material list Organisational Geographical Event list
unit & role list locations list

Conceptual Goal relationship Process model Entity Organisational unit Locations model Event model
relationship & role relationship
model model
Logical Rules diagram Process diagram Data model Role relationship Locations Event diagram
diagram diagram diagram

Physical Rules Process function Data entity Role specification Location Event
specification specification specification specification specification

Detailed Rules details Process details Data details Role details Location details Event details

“The [enterprise architecture] framework as it applies to enterprises is simply a

logical structure for classifying and organising the descriptive representations
of an enterprise that are significant to the management of the enterprise, as
well as to the development of the enterprise's systems” – John Zachman48

PROS CONS
– A useful way of organising business concepts – Is a structure, not a methodology
– Articulates that no single unified architecture can – Can help arrange concepts without providing
meet an organisation’s needs, enabling a richer set guidance on what to do with them
of architectures to be developed – Requires the architect to conduct a very granular
– A good starting point for enterprise architecture analysis of subjective data; however, does not
and security architecture help with clarifying if decisions made on the to-be
– Provides the fundamentals needed for business architecture are the most practical
systems planning and design – Does not provide reference model guidance or support
– Can provide an effective metamodel when creating on how to implement an enterprise architecture
the architecture of a large-scale information system – Easy to become immersed in detailed tasks such
– Helps develop and depict a wide variety of processes, as creating models, developing standards, and
tools and methodologies and their interdependencies communicating detailed concepts to various
business stakeholders

48 Zachman, John A. "The Framework for Enterprise Architecture: Background, Description and Utility." Zachman Institute for Framework Advancement (ZIFA)

Information Security Forum Security Architecture: Navigating complexity 31

 APPENDIX B:
Further reading
A range of ISF reports and discussions on ISF Live can support Members’ efforts with
developing and using security architectures. They are grouped into three categories:

1 – Strategic and managerial related

ACTIVITY ISF DELIVERABLES
Developing a forward- Information Security Strategy:
thinking business integrated Transitioning from alignment to integration
strategy

Engaging with senior Engaging with the Board:

management Balancing cyber risk and reward
Engaged Reporting: Fact and fortitiude
The Modern CISO: Managing risk and delivering value

Managing information risk Information Risk Assessment Methodology 2

in the enterprise (IRAM2)

Measuring and Time to Grow: Using maturity models

communicating value to create and protect value
Information Security Governance: Raising the game

2 – Topic related
Embedding information Supply Chain Assurance Framework:
security considerations into Contracting in confidence
the contracting and supplier
management processes

Improving cloud security Securing Cloud Computing:

Addressing the seven deadly sins

Managing privacy Data Privacy in the Cloud:

obligations when Enabling business agility by managing risk
leveraging the benefits
of the cloud

3 – Supplier related
Embedding a positive From Promoting Awareness to Embedding
information security Behaviours: Secure by choice, not by chance
culture in the organisation

Adopting information The Standard of Good Practice for

security controls and Information Security
principles ISF Benchmark

32 Security Architecture: Navigating complexity Information Security Forum

BENCHMARK
 ACKNOWLEDGEMENTS
The ISF would like to thank all ISF Members and external experts who contributed to this report by being
interviewed, emailing ideas, posting comments on ISF Live and attending the Solution Development Workshops
in Amsterdam, London, Munich, New York and Toronto.

MEMBERS
Peter Lidell ..................................... A.P. Moller Maersk Kaapro Kanto.............................................. TeliaSonera
Bent Larsen.....................................A.P. Moller-Maersk Brian Monkman.............................................. ICSA labs
Gerard van Seventer........................................ Achmea Pep Gallenkamp.................International Card Services
Rob Faber......................................................... Achmea Clive Payne.....................................................JPMorgan
Anton Litzlbeck................... Airbus Defence and Space Adrian Seccombe..........................Leading Edge Forum
Chris van den Brink...................................... AkzoNobel Stephen Rees............................. Lloyds Banking Group
Arjan Zwikker............................................... AkzoNobel Dirk Loomans............................... Loomans & Matz AG
Aad Dekker...................................................... Alliander Roland Mueller.....................................Mercedes Benz
Bhupesh Rana.........................................................AXA Saif Jafri.................................................... Mizuho Bank
Runli Guo................................................................ AXA Joe Zhou................................................... Mizuho Bank
Holger Petersen................................................BASF SE Richard Hudson....................................... Mizuho Bank
Michael Altmaier..............................................BASF SE Sajani Kattipally ....................................... Mizuho Bank
William Sickle................................... Baxter Healthcare Enrico Massi................................................... Monetise
Theresa Castillo-Lalonde............................Bell Canada Doris Altenkamp.................................... MS Consulting
George Perkins.........................................Betfair Group Alexander Slepitschka.................................. Munich RE
Sebastian Sanchez...................................Betfair Group Simon Gray............................................... National Grid
Jamie Rossato ........................................................ BNZ Christian Gillstrap............Nationwide Building Society
Jari Pesonen........................................................ Canon Gudrun Fedorowich.........Nationwide Building Society
Guido Van Gelderen........................................... Canon Sander Meijer..................... Nederlandse Spoorwegen
Mark Battersby.............................................Capgemini Brian Todd..................................................... NN Group
Alex Stezycki..................................................Capgemini Renato Kuiper........................................................... NS
Dominic Howitt.............................................Capgemini Chris Morales.................................................. NSS Labs
John Arnold...................................................Capgemini Hubert Kirchgaessner...................... Procter & Gamble
Jeremy Wilde................................................... Centrica Sebastian Kremer............................. Procter & Gamble
Boubacar Fadiga...................................................... CGI Inderpal Dhami ......................................................PwC
Albert Chen............................................................ CIBC Cathy Brough..........................................................PwC
Jeff Gross............................................................. CIGNA William Beshilas......................................................PwC
Jennifer Bayuk..........................................................CITI Edward Hamilton ...................................................PwC
Murray Rosenthal..................................City of Toronto Nalneesh Gaur........................................................PwC
John Franks...............................The Co-operative Bank John Sluiter.............................................................PwC
Tom White................................The Co-operative Bank Tom Urquhart.........................................................PwC
Tim Wilson.................................Córas Iompair Éireann Daljitt Barn..............................................................PwC
Thomas Donner................................................Deloitte Matt Burns..............................................................PwC
Paul McKay........................................................Deloitte Dinesh Nagarajan....................................................PwC
Jeroen Jaspers........................................................ DSM Jonny Kapacee........................................................PwC
Suchun Wu........................................................ eHealth Paul Samwel.................................................. Rabobank
Mark Carter....................................................... eHealth Eric Kaasenbrood.......................................... Rabobank
Steve Greenham........................................................ EY Ove Liljeqvist .................................................... Samlink
Ian Argile............................................................. Fujitsu Richard Sargeant...................................................... SSE
Marcus Schmid....................................................... IBM Maurice Smit.................................The SABSA Institute
Michael Meli.................................................. Swisscom Courage Ackuaku.............................. Thomson Reuters
David Shaw....................................................Symantec Andy Boura....................................... Thomson Reuters
Arif Hameed..................................................... TD Bank Mark Ellis................................................................ TNSI
Sebastian Piecha .......................................... Telefonica Arshid Bashir........................................... TSL Education
Joerg Schreck................................................ Telefonica Petri Jokela....................................................... Wärtsilä
Johnny Mathisen...............................................Telenor Simon Martin................................................. Worldpay

EXTERNAL CONTRIBUTORS
Steve Jennings..................................Adelante Partners Roger Sessions..........................................ObjectWatch
Samuel Holcman......Enterprise Arch. Center Of Excellence Piers Wilson.......................................................... Tier-3

As always, because ISF Members are providing information that may be about their own organisation, their
contributions are anonymous. These acknowledgements show the individuals and the organisations they
represented at the time they contributed to this project. Please accept our apologies for any omissions from the list.
The views, opinions and comments in this report are not necessarily those of the ISF, its Member organisations
or external contributors.

Information Security Forum Security Architecture: Navigating complexity 33

ABOUT ISF
Founded in 1989, the Information Security Forum (ISF)
is an independent, not-for-profit association of leading
organisations from around the world. It is dedicated
to investigating, clarifying and resolving key issues in
cyber, information security and risk management and
developing best practice methodologies, processes and
solutions that meet the business needs of its Members.
ISF Members benefit from harnessing and sharing
in-depth knowledge and practical experience drawn from
within their organisations and developed through an
extensive research and work program. The ISF provides
a confidential forum and framework, which ensures
that Members adopt leading-edge information security
strategies and solutions. And by working together,
Members avoid the major expenditure required to
reach the same goals on their own.

FOR FURTHER
INFORMATION CONTACT:
Information Security Forum
Tel: +44 (0)20 7213 1745
Email: info@securityforum.org
Web: www.securityforum.org

REFERENCE: ISF 01 03 16
Copyright©2016 Information Security Forum Limited. All rights reserved.