Download SABSA White Paper PDF

TitleSABSA White Paper
File Size191.7 KB
Total Pages17
Table of Contents
                            Executive Summary
The Origins of Architecture
Information Systems Architecture
Managing Complexity
Enterprise Security Architecture
Why Architectures Sometimes Fail to Deliver Benefit
	Historical Background
	The Wider Business Requirements
		Usability
		Inter-Operability
		Integration
		Supportability
		Low Cost Development
		Fast Time to Market
		Scalability of Platforms
		Scalability of Cost
		Scalability of Security Level
		Re-Usability
		Operations Costs
		Administration Costs
		Risk-Based Cost/Benefit Effectiveness
		Enabling Business
Being a Successful Security Architect
Security Architecture Needs a Holistic Approach
The SABSA® Model
	A Layered Model of Architecture
		The Business View
		The Architect’s View
		The Designer’s View
		The Builder’s View
		The Tradesman’s View
		The Facilities Manager’s View
		The Inspector’s View
The SABSA® Matrix
The SABSA® Development Process
The SABSA® Lifecycle
The SABSA® Business Attributes Profile
SABSA® Implementation
Architecture Maintenance
Summary and Conclusion
Further Information
SABSA Institute Education and Certification
                        
Document Text Contents
Page 1

1995 – 2007 SABSA Limited | [email protected] Page 1 of 17

White Paper

Enterprise Security Architecture
John Sherwood, Andrew Clark & David Lynas

Contact: [email protected]



Executive Summary
SABSA®1 is a model and a methodology for developing risk-driven enterprise information security architectures
and for delivering security infrastructure solutions that support critical business initiatives. At the heart of this
methodology is the SABSA® Model, a top-down approach that drives the SABSA® Development Process. This
process analyses the business requirements at the outset, and creates a chain of traceability through the strategy
& concept, design, implementation and ongoing ‘manage and measure’ phases of the SABSA® Lifecycle to
ensure that the business mandate is preserved. The whole methodology is further supported by framework tools
created from practical experience, including the SABSA® Matrix and the SABSA® Business Attributes Profile.

This white paper explores the advantages of this business-focused model for creating security architecture. It
discusses the pitfalls of a technology-centric approach, and recognises the challenges of integrating the business
leaders with the technology strategists in order to fulfil the potential of the enterprise.

The paper also discusses the SABSA® methodology, explaining this approach by comparing it to the classical
definition of architecture (i.e., the construction of buildings). By illustrating the contextual, conceptual, logical,
physical, component-oriented and operational layers of the architectural process, a comprehensive approach
unfolds that provides a roadmap for business and information and communications technology (ICT) leadership
to follow to ensure the technology foundation becomes an enabler of business performance.

The Origins of Architecture
Architecture has its origins in the building of towns and cities, and everyone understands this sense of the word,
so it makes sense to begin by examining the meaning of ‘architecture’ in this traditional context.

Architecture is a set of rules and conventions by which we create buildings that serve the purposes for which we
intend them, both functionally and aesthetically. Our concept of architecture is one that supports our needs to
live, to work, to do business, to travel, to socialise and to pursue our leisure. The multiplicity and complex
interaction of these various activities must be supported, and this includes the relationship between the activities
themselves and their integration into a whole lifestyle. Architecture is founded upon an understanding of the
needs that it must fulfil.

These needs are expressed in terms of function, aesthetics, culture, government policies and civil priorities.
They take into account how we feel about ourselves and about our neighbours, and how they feel about us. In
these various ways, architecture must serve all those who will experience it in any way.

Architecture is also both driven and constrained by a number of specific factors. These include: the materials
available within the locale that can be used for construction; the terrain, the prevailing climate; the technology;
and the engineering skills of the people.







1 SABSA®: Sherwood Applied Business Security Architecture – a registered trademark of SABSA Limited

mailto:[email protected]

Page 2

As a result, there are fundamentally three major factors that determine what architecture we will create:

Our goals

The environment

Our technical capabilities

Information Systems Architecture
The concept of ‘architecture’ in buildings has been adapted to areas of life other than the building of towns and
cities. For example one talks about a ‘naval architect’ being someone that designs and supervises the
construction of ships. In more recent times the term has been adopted in the context of designing and building
business computer systems, and so the concept of ‘information systems architecture’ has been born.

In the same way that conventional architecture defines the rules and standards for the design and construction of
buildings, information systems architecture addresses these same issues for the design and construction of
computers, communications networks and the distributed business systems that are implemented using these
technologies.

As with the conventional architecture of buildings, towns and cities, information systems architecture must
therefore take account of:

The goals that we want to achieve through the systems

The environment in which the systems will be built and used

The technical capabilities needed to construct and operate the systems and their component sub-systems

If one accepts this analysis then one is already well on the way to recognising that information systems
architecture is concerned with much more than mere technical factors. It is concerned with what the enterprise
wants to achieve and with the environmental factors that will influence those achievements.

In some organisations this broad view of information systems architecture is not well understood. Technical
factors are often the main ones that influence the architecture, and under these conditions the architecture can
fail to deliver what the business expects and needs.

This document is mainly concerned only with one aspect of information systems architecture: that is the security
of business information systems. However, in addressing this specialist area the authors have tried to provide as
much advice as possible on how to take the broader view. Thus the focus is on an ‘enterprise security
architecture’, to emphasise that it is the enterprise and its activities that are to be secured, and that the security of
computers and networks is only a means to this end.

Managing Complexity
One of the key functions of ‘architecture’ as a tool of the architect is to provide a framework within which
complexity can be managed successfully. Small, isolated, individual projects do not need ‘architecture’, because
their level of complexity is limited and the chief designer can manage the overall design single-handed.
However, as the size and complexity of a project grows, then it is clear that many designers are needed, all
working as a team to create something that has the appearance of being designed by a single ‘design authority’.

Also, if an individual project is not isolated, but rather is intended to fit harmoniously within a much wider, highly
complex set of other projects, then an architecture is needed to act as a ‘road-map’ within which all of these
projects can be brought together into a seamless whole. The result must be as though they were all indeed part
of a single, large, complex project. This applies whether the individual projects are designed and implemented
simultaneously, or whether they are designed and implemented independently over an extended period of time.

As complexity increases, then a framework is needed within which each designer can work, contributing to the
overall design. Each design team member must also be confident that his/her work will be in harmony with that
of colleagues and that the overall integrity of the design will not be threatened by the work being split across a
large design team.

1995 – 2007 SABSA Limited | [email protected] Page 2 of 17

Page 8

Figure 1: The SABSA® Model for Security Architecture

Contextual Security Architecture

Conceptual Security Architecture

Logical Security Architecture

Physical Security Architecture

Component Security Architecture

O
perational S

ecurity A
rchitecture

Contextual Security Architecture

Conceptual Security Architecture

Logical Security Architecture

Physical Security Architecture

Component Security Architecture

O
perational S

ecurity A
rchitecture

The Business View
When a new building is commissioned, the owner has a set of business requirements that must be met by the
architecture. At the highest level this is expressed by the descriptive name of the building: it is a domestic house;
a factory; an office block; a sports centre; a school; a hospital; a warehouse; a theatre; a shopping centre; an
airport terminal; a railway station; or whatever. Each one of these business uses immediately implies an
architecture that will be different from all the others, an architecture that will fulfil expectations for the function of
the building in business terms.

Having stated what sort of building is needed the owner must then decide some more detail about its use:

Why do you want this building? The goals that you want to achieve.

How will it be used? The detailed functional description.

Who will use the building, including the types of people, their physical mobility, the numbers of them
expected, and so on?

Where should it be located, and what is its geographical relationship to other buildings and to the
infrastructure (such as roads, railways etc)?

When will it be used? The times of day / week / year, and the pattern of usage over time.

This type of analysis is essential before any type of design work is done. It is through this process that the
requirements of the building are established, and understanding the requirements is a pre-requisite to designing
a building that will meet those requirements. When you design a secure business system, the same applies.
There are many possible architectural approaches that you could take, but the one that will be the most suitable
will be driven from a clear understanding of the business requirements for the system.

What type of system is it and what will it be used for?

Why will it be used?

How will it be used?

Who will use it?

Where will it be used?

When will it be used?

1995 – 2007 SABSA Limited | [email protected] Page 8 of 17

Page 9

These are the characteristic questions that you must ask. From the analysis of the replies you receive, you
should be able to gain an understanding of the business requirements for the secure system. From those you
should be able to synthesise a systems architecture and a security architecture that meets those requirements.

In the SABSA® Model this business view is called the contextual security architecture. It is a description of the
business context in which your secure systems must be designed, built and operated.

Any attempt to define an architecture that takes a short cut and avoids this essential step is very unlikely to be
successful. Even so, simple observation reveals that many enterprises undertaking architectural work do not
take this stage seriously. It is very common for systems architecture work to begin from a technical perspective,
looking at technologies and solutions whilst ignoring the requirements.

It seems to be such obvious common sense that one must first understand the requirements, and yet so few
people seem to know how to approach architecture development in the information systems arena. Unfortunately
many technologists and technicians believe that they already know the requirements, even though they have a
poor relationship with those who might express these requirements.

The results of taking a short cut in the requirements definition stages of an architecture development are
abundantly clear. When one looks around at many large corporate enterprises and at their information systems
infrastructure managers or applications teams, the relationship with the business community is often strained.
For many years the ‘business people’ have been complaining that the ‘information systems people’ are unable to
deliver what the business needs, and that ICT is a serious source of cost with very little tangible benefit to show
for it. The reason is simple: the business people are right. ICT vendor interests and technical innovations often
drive business systems development strategy, rather than it being driven by business needs. Those with
responsibility for architecture and technical strategy often fail to understand the business requirements because
they do not know how to do otherwise. Ignorance of architectural principles is commonplace.

We describe here how to take a layered approach to security architecture development. Many of you will be
tempted to flip the pages to get to the end sections where some of the solutions can be found. You are in a hurry,
and whilst you know that this step-wise approach is correct, you simply do not have the time to linger on the
appetisers and starters – you need to get to the meat course. Well, be warned. There simply is no substitute for
doing architecture work the proper way. You may try to take short cuts, but your efforts will most likely result in
failure, which costs the business more money, delivers less benefit, and destroys the confidence that business
people may have in information and communications technology as the means to enable business development.

In the model presented here, the contextual architecture is concerned with:

What? The business, its assets to be protected (brand, reputation, etc.) and the business needs for
information security (security as a business enabler, secure electronic business, operational continuity and
stability, compliance with the law, etc.).

Why? The business risks expressed in terms of assets, goals, success factors and the threats, impacts and
vulnerabilities that put these at risk, driving the need for business security (brand protection, fraud
prevention, loss prevention, legal obligations, business continuity, etc.).

How? The business processes that require security (business interactions and transactions, business
communications, etc.).

Who? The organisational aspects of business security (management structures, supply chain structures,
out-sourcing relationships, strategic partnerships).

Where? The business geography and location-related aspects of business security (the global village
market place, distributed corporate sites, remote working, etc.).

When? The business time-dependencies and time-related aspects of business security in terms of both
performance and sequence (business transaction throughput, lifetimes and deadlines, just-in-time
operations, time-to-market, etc.).

1995 – 2007 SABSA Limited | [email protected] Page 9 of 17

Page 16

1995 – 2007 SABSA Limited | [email protected] Page 16 of 17



also allows the selection of metrics that are used to set performance targets as an integral part of the SABSA®
Business Attributes Profile th o is at the choice of the
business analysts, using eith attributes, or creating new

tegy & Concept’ activity, and which has been customised specifically to
conceptualise this unique business.

The SABSA Lifecycle contains an activity called ‘Implement’. However, it is unlikely that a major strategic
implemented as a single project. What is more likely is that the
that guides a whole series of separate implementation projects,

.


s fragmentation does not lead to a piecemeal approach to design. Despite the

fragmented projects, the overall systems environment should maintain its architectural integrity – provided that


Figure 4: The SABSA® Taxonomy of Business Attributes

It
at can later be measured (did you hit the target?). This to
er the suggested metrics in the detailed definitions of the

metrics if it seems more appropriate.

Thus the ‘Manage & Measure’ activity in the SABSA® Lifecycle is based upon the SABSA® Business Attributes
Profile that was set out during the ‘Stra

SABSA® Implementation
®

enterprise-wide security architecture will ever be
architecture provides a blue-print and a road-map
each of which is driven by a specific business initiative and funded by a budget associated with that initiative
Some of these projects may themselves be ‘infrastructure projects’, such as building an integrated, enterprise
wide, unified directory service.

The reality is that implementation will usually be fragmented in this way. Thus the main purpose of the security
architecture is to ensure that thi

the architecture has been created and documented, and provided that project teams refer to it and are guided by
it. Individual projects should therefore be subject to architectural approval by an Architecture Board.

Business Attributes

Management
Attributes

User
Attributes

Operational
Attributes

Risk Management
Attributes

Technical Strategy
Attributes

Flexible / Adaptable

Scalable

Upgradeable

Usable

Accessible

Cost-Effective

Efficient

Reliable

Inter-Operable

Trustworthy

Reputable

Business Strategy
Attributes

Credible

Confident

Crime-Free

Insurable

Compliant

Confidential

Private

Controlled

Liability Managed

Admissible

Resolvable

Available

Legal / Regulatory
Attributes

EnforceableError-Free

Non-Repudiable

Accountable

Auditable

Traceable

Integrity-Assured

Assurable

Authorised

Governable

Business-Enabled

Protected

Independently Secure

Measured

Legacy-Sensitive

Migratable

Flexibly Secure

Productive

COTS / GOTS

Simple
Providing Investment
Re-use

Supportable

Automated

Standards Compliant

Architecturally Open

Future-Proof

Capturing New Risks Multi-Sourced

Extendible

Maintainable

Consistent

Accurate

Current

Supported

Access-controlled

In our sole possession

Change-managed

Informed

Owned

Identified

Authenticated

Time-bound

Timely

Providing Good Stewardship
and Custody

Assuring Honesty

Educated & Aware

Motivated

RecoverableDuty Segregated

Detectable

Brand Enhancing

Competent

Transparent

Responsive

Anonymous Continuous

Monitored

Legal

Regulated

Providing Return
on Investment

Enabling time-to-market

Culture-sensitive

Business Attributes

Management
Attributes

User
Attributes

Operational
Attributes

Risk Management
Attributes

Technical Strategy
Attributes

Flexible / Adaptable

Scalable

Upgradeable

Usable

Accessible

Cost-Effective

Efficient

Reliable

Inter-Operable

Trustworthy

Reputable

Business Strategy
Attributes

Credible

Confident

Crime-Free

Insurable

Compliant

Confidential

Private

Controlled

Liability Managed

Admissible

Resolvable

Available

Legal / Regulatory
Attributes

EnforceableError-Free

Non-Repudiable

Accountable

Auditable

Traceable

Integrity-Assured

Assurable

Authorised

Governable

Business-Enabled

Protected

Independently Secure

Measured

Legacy-Sensitive

Migratable

Flexibly Secure

Productive

COTS / GOTS

Simple
Providing Investment
Re-use

Supportable

Automated

Standards Compliant

Architecturally Open

Future-Proof

Capturing New Risks Multi-Sourced

Extendible

Maintainable

Consistent

Accurate

Current

Supported

Access-controlled

In our sole possession

Change-managed

Informed

Owned

Identified

Authenticated

Time-bound

Timely

Providing Good Stewardship
and Custody

Assuring Honesty

Educated & Aware

Motivated

RecoverableDuty Segregated

Detectable

Brand Enhancing

Competent

Transparent

Responsive

Anonymous Continuous

Monitored

Legal

Regulated

Providing Return
on Investment

Enabling time-to-market

Culture-sensitive

Page 17

Architecture Maintenance
®A security architecture developed using the SABSA Methodology is not shelf-ware – it is a living, breathing thing
Certainly it is a reference document that should be used by
ecific business-led projects (see above under

ses – at what point do the contextual changes create sufficient
cture and other layers? Technology also changes. New

Unless the security architecture can address a wide range of operational requirements and provide real business
pon short-term point solutions, then it will likely fail to deliver
ommon phenomenon throughout the information systems




who
their objections, you must be a good communicator who can sell

these ideas and these benefits to others in the enterprise.

chieved unless the most senior decision-makers are
on your side. To achieve this level of backing, senior management must feel that their success is directly tied to

For those who would like greater detail on this subject, there is a major reference work (587 pages) entitled:
iness Driven Approach'; ISBN 1-57820-318-X

P

ttp://books.elsevier.com/us//cmpbooks/us/subindex.asp?maintarget=&isbn=&country=United+States&srccode=
k

For details on the SABSA Institute’s comprehensive education and certification programme please visit

that needs to be maintained and applied constantly.
project teams as they design and implement their sp
‘Implementation’). However, the world is constantly changing. The business requirements evolve over time.
Sometimes they experience a step change as a major acquisition or divestment occurs, sometimes they evolve
slowly in response to a changing marketplace.

Whatever the case, the front end of the architecture – the contextual architecture – needs to be reviewed and
updated from time to time. The question then ari
pressure to change the underlying conceptual archite
solutions become available. Again this raises a question – at what point should you change decisions in the
component architecture from one strategic technology or product to another? All of this suggests some kind of
continual architecture review process, governed by an Architecture Board.

Summary and Conclusion
support and enablement, rather than just focusing u
what the business expects. This type of failure is a c
industry, not just in the realm of security architecture. Yet it is not sufficient to compile a set of business
requirements, document them and then put them on the shelf, and proceed to design a security architecture
driven by technical thinking alone. Being a successful security architect means thinking in business terms at all
times, and setting up quantifiable success metrics that are developed in business terms around business
performance parameters, not technical ones.

Another challenge is the sheer number of other people who do not understand strategic architecture, and
think only in terms of technology. To overcome

One of the most important factors for success is gaining buy-in and sponsorship from senior management within
the enterprise. Enterprise security architecture cannot be a

the success of the architecture. Creating this environment of acceptance and support is probably one of the most
difficult tasks, since it may force the enterprise as a whole to begin to think and act in a very different way.
However, if a business-driven approach is utilized, the fruits of the architectural work will be enjoyed throughout
the enterprise.

Further Information
'Enterprise Security Architecture: A Bus

To purchase the book directly from the publisher, or to read reviews by prominent professionals, click on “CM
Books” at the top right corner of the Elsevier web site:
h
&ref=&subcode=&head=&pdf=&basiccode=&txtSearch=&SearchField=&operator=&order=&community=cmpboo
s
The book of SABSA is also available from all major bookstores and on-line book sellers.

SABSA Institute Education and Certification
http://www.sabsa.org



1995 – 2007 SABSA Limited | [email protected] Page 17 of 17

Similer Documents