Enterprise Security Architecture was initially targeted to address two problems
1- System complexity
2- Inadequate business alignment
Resulting into More Cost, Less Value
2. Enterprise Architecture
• A field born about 30 years ago
• Initially targeted to address two problems
– System complexity
– Inadequate business alignment
– Resulting into
• More Cost, Less Value
4. A Brief History of Enterprise Architecture
Zachman’s first article
1987
TAFIM released
1994
Clinger-Cohen bill passed
1996 1998
TAFIM retired
FEAF 1.2 released
1999 2002
FEA replaces FEAF
TOGAF EE 8.0 released
2003 2003
FEA mostly complete
2011
TOGAF 9.1
5. Zachman Framework (1)
• The Zachman "Framework" is actually a taxonomy for organizing
architectural artifacts (in other words, design documents, specifications,
and models) that takes into account both who the artifact targets (e.g.
business owner and builder) and what particular issue (e.g. data and
functionality) is being addressed
• Two dimensions
– Players in the game
– Architectural Artifacts
• Players in the game: Actors
• Architectural Artifacts: the What, How, Where, When, Who and Why
• The second dimension is independent of the first
– Both the Builder and the Owner need to know the ‘What’
– But, they need to know different ‘What’
• From a Business Owner’s perspective, ‘Data’ means business entity
– Example: Customer, Product, Demographic Groups, Inventory
• From the developer’s perspective i.e. Builder’s perspective, ‘Data’ means
rows and columns organized into table, mathematical joins to implement
relationships
6. Zachman Framework (2)
• Zachman Framework is typically depicted as a 6 x 6 matrix
– Columns: Communication Interrogatives
– Rows: Reification Transformation
– The Framework Classification is represented by 36 cells
– Each cell represents a player’s perspective (e.g. business owner) and a
descriptive focus (e.g. data)
• Moving horizontally changes description of the system from
same player’s perspective
• Moving vertically pin down to single focus but changes players
8. How Zachman Taxonomy can help building a system
architecture
• First: use Zachman Taxonomy to the fact that every
architecture artifact must live in one and only one cell
• Second: achieve architectural completeness by completing
every cell
• Third: cells in columns should be related to each other.
9. Five Ways Zachman Taxonomy can help building
enterprise architecture
• Five ways Zachman Taxonomy can help:
– Ensure that every stakeholder's perspective has been
considered for every descriptive focal point
– Improve the Enterprise Architecture artifacts themselves
by sharpening each of their focus points to one particular
concern for one particular audience
– Ensure that all of CxO’s business requirements can be
traced down to some technical implementation
– Convince Business function of the organization that the
technical team isn't planning on building a bunch of
useless functionality
– Convince Technology team that the business folks are
including IT teams in their planning
10. What Zachman Taxonomy does not
provide
• Does not provide step-by-step process to create new
architecture
• Does not provide much help in validating an
architecture
• Does not provide help in deciding future architecture
11. Cyber Security Frameworks
• A Cyber Security Framework is a risk-based
compilation of guidelines designed to help
organizations assess current capabilities and
draft a prioritized roadmap toward
improved cybersecurity practices
Source: NIST
12. Well Known Cyber Security
Frameworks
• ISO/IEC 27001 & 27002 (formerly ISO 17799)
• NIST SP 800-53: Security and Privacy Controls
for Federal Information Systems and
Organizations
• Sherwood Applied Business Security
Architecture (SABSA)
• NIST SP 800-39: Risk Management Framework
• Security in Major IT Management Frameworks
13. What is SABSA
• Methodology for:
– Developing business-driven, risk and opportunity focused enterprise
security & information assurance architectures
– Delivering security infrastructure & service management solutions
that traceably support critical business initiatives
• Comprised of a number of integrated frameworks, models, methods and
processes, including:
– Business Requirements Engineering Framework (also known as
Attributes Profiling)
– Risk & Opportunity Management Framework
– Policy Architecture Framework
– Security Services-Oriented Architecture Framework
– Governance Framework
– Security Domain Framework
– Through-life Security Service & Performance Management
15. How is SABSA Used
• Information Assurance
• Governance, Compliance & Audit
• Policy Architecture
• Security service management
• IT Service management
• Security performance
management, measures &
metrics
• Service performance
management, measures &
metrics
• Over-arching decision-making
framework for end-to-end
solutions
• Enterprise Security Architecture
• Enterprise Architecture
• Individual solutions-based
Architectures
• Seamless security integration &
alignment with other frameworks
(including TOGAF, ITIL, ISO27000
series, Zachman, DoDAF, CobIT,
NIST, etc.)
• Filling the security architecture
and security service management
gaps in other frameworks
• Business requirements
engineering
• Solutions traceability
• Risk & Opportunity Management
16. Sherwood Applied Business Security Architecture
(SABSA) Model
SABSA Model
The SABSA Model comprises six layers. It is based on the well-known Zachman framework1
for developing
model for enterprise architecture, although it has been adapted somewhat to a security view of the world.
17. SABSA Model
• Comprises of six layers
• Based on Zachman framework/taxonomy
• The Security Service Management Architecture has been
placed vertically across the other five layers
– Security management issues arises in every horizontal layer
• Each horizontal layers are made of a series of vertical
communication interrogatives
– What (Assets)
– Why (Motivation)
– How (Process and Technology)
– Who (People)
– Where (Location)
– When (Time)
23. Approach of Discussing SABSA
• Business Context and Requirements
• Policy Architecture
• Architecture Strategies
• Planning and Performance Management
• Scope of current discussion
– Business context and requirements
– Architecture strategies
– Planning and performance management
• They would be discussed in terms of framework
and implementation
26. Scope: Strategy & Planning Phase -
Assets
Business Driver Development
BAP with KPI’s and KRI’s
27. Business Driven Architecture
• Being business-driven means never losing site of the
organisation’s goals, objectives, success factors and
targets, and ensuring that the security strategy
demonstrably supports, enhances and protects them
• The contextual architecture captures and presents the
full set of relevant requirements for the scope of the
assignment
– Including conflicts in business strategy, risks & priorities
– At this stage we are confirming that they are complete and
we understand them
– The conceptual layer will later resolve these conflicts by
delivering an appropriate, measurable security strategy
28. Credible Abstraction is Key
• Meaningful traceability is enabled by credible abstraction from business context
(assets, goals & objectives) to a business security context
• Traceability therefore starts by delivering two slightly different sets of
requirements:
29. Business Attributes
• An Attribute is a conceptual abstraction of a real
business requirement (the goals, objectives,
drivers, targets, and assets confirmed as part of
the business contextual architecture)
• The Attributes Profiling technique enables any
unique set of business requirements to be
engineered as a standardized and re-usable set
of specifications
• The Attributes are modeled into a normalized
language that articulates requirements and
measures performance in a way that is
instinctive to all stakeholders
30. Attributes Profiling Rules & Features
• Attributes can be tangible or intangible
• Each attribute requires a meaningful name and detailed definition
customized specifically for a particular organization
• Each attribute requires a measurement approach and metric to be
defined during the SABSA Strategy & Planning phase to set
performance targets for security
• Attributes must be validated (and preferably created) by senior
management & the business stake-holders by report, interview or
facilitated workshop
• The performance targets are then used as the basis for reporting
and/or SLAs in the SABSA Manage & Measure phase
• Powerful requirements engineering technique
• Populates the vital ‘missing link’ between business requirements
and technology / process design
33. Sample of Business Drivers
Driver # Business Drivers
BD1
Protecting the reputation of the Organization, ensuring that it is perceived as
competent in its sector
BD2
Providing support to the claims made by the Organization about its competence
to carry out its intended functions
BD3
Protecting the trust that exists in business relationships and propagating that
trust across remote electronic business communications links and distributed
information systems
BD4
Maintaining the confidence of other key parties in their relationships with the
Organization
BD5 Maintaining the operational capability of the Organization’s systems
BD6
Maintaining the continuity of service delivery, including the ability to meet the
requirements of service level agreements where these exist
BD7 Maintaining the accuracy of information
BD8 Maintaining the ability to govern
36. Business Attributes
Business
Attributes
User Attributes
Management
Attributes
Risk
Management
Attributes
Legal/Regulatory
Attributes
Technical
Strategy
Attributes
Operational
Attributes
Business
Strategy
Attributes
Business
Attribute Business Attribute Definition Suggested Measurement Approach Metric Type
User Attributes
Accessible Information to which the user is entitled to gain access
should be easily found and accessed by that user.
Search tree depth necessary to find the information
Soft
Accurate
The information provided to users should be accurate
within a range that has been preagreed upon as being
applicable to the service being delivered.
Acceptance testing on key data to demonstrate
compliance with design rules Hard
Anonymous
For certain specialized types of service, the anonymity
of the user should be protected.
Rigorous proof of system functionality
Red team review
Hard
Soft
Consistent
The way in which log-in, navigation, and target services
are presented to the user should be consistent across
different times, locations, and channels of access.
Conformance with design style guides Red team review
Soft
Current
Information provided to users should be current and
kept up to date, within a range that has been pre-
agreed upon as being applicable for the service being
delivered.
Refresh rates at the data source and replication of
source and replication of refreshed data to the
destination.
Hard
37. Attribute Profile
Business
Attributes
User Attributes
Management
Attributes
Risk
Management
Attributes
Legal/Regulatory
Attributes
Technical
Strategy
Attributes
Operational
Attributes
Business
Strategy
Attributes
Business
Attribute
Business
Driver Business Attribute Definition Measurement Approach Metric
Performance
Target
User Attributes
Accessible 5
Information to which the user is entitled to gain
access should be easily found and accessed by that
user.
Search tree depth necessary to find the
information
Soft
Accurate 7
The information provided to users should be accurate
within a range that has been preagreed upon as
being applicable to the service being delivered.
Acceptance testing on key data to
demonstrate compliance with design rules Hard
Anonymous 4
For certain specialized types of service, the
anonymity of the user should be protected.
Rigorous proof of system functionality
Red team review
Hard
Soft
Consistent 23, 41
The way in which log-in, navigation, and target
services are presented to the user should be
consistent across different times, locations, and
channels of access.
Conformance with design style guides
Red team review
Soft
Current 7
Information provided to users should be current and
kept up to date, within a range that has been
preagreed upon as being applicable for the service
being delivered.
Refresh rates at the data source and
replication of source and replication of
refreshed data to the destination.
Hard
40. Alignment, Integration & Compliance Strategy
• Understand what needs to be aligned, to what
purpose, and where it is positioned within the SABSA
framework
• Business model or business process framework
• Legislation, regulation or governance frameworks
• Risk management methods, assurance framework or
audit approach
• IT Architecture framework or method
• Controls framework, library or standard
• Performance management & reporting framework
47. Application of Multi-tiered Controls In Risk
• The multi-tiered controls strategy is modeled against
the risk assessment to determine proportional and
appropriate response
• Contributes to selection of the right control in the right
place at the right time
• Enables further removal of subjectivity in selection of
Risk Treatments
• Facilitates construction of databases and risk
management tools that respond to definitive risk
scenarios with definitive control decisions
• Increases speed and ease of use of Risk Assessment
54. Implementation Phase & Approach
• Implementation is an important part of the lifecycle but the
SABSA Matrix does not define a specific implementation
layer
– No need to re-invent Prince2 or PMI etc.
• Notoriously difficult to gain business support and budget
for pure infrastructure projects
• Rare that a major strategic enterprise-wide security
architecture is implemented as a single project
• More likely (and more sensible) is that the architecture
provides a blue-print and a road-map that guides a whole
series of separate implementation projects, each of which
is driven by a specific business initiative and funded by a
budget associated with that initiative
55. Manage & Measure Phase – Lifecycle Overlay
• SABSA Architecture traceably abstracts from pure
Business Context to:
– Pure technical deployment in the Component layer
– Pure management in the Service Management layer
• The Service Management layer defines all aspects
of security management and constructs the
means to manage and incorporate change by
being presented vertically across the other layers:
– Strategy (Context & Concept Layers)
– Tactics (Logical, Physical, & Component Layers)
– Operations (Security Service Management Matrix)
61. Process Improvement Framework –
SABSA Maturity Profile (SMP)
• Coordinates SABSA process information from all parts of the business
– Demonstrates due diligence to senior management, auditors and regulators
• Based on Capability Maturity Modeling (CMM) concepts
– Qualitative measurement technique for maturity of processes
– Six domains mapped onto the SABSA Matrix
– Consistent, objective 5-point maturity scale
• Identifies, measures and reports compliance practices
– Against the SABSA framework, model and processes
– Provides a gap analysis to drive a SABSA improvement programme
• Can be implemented through a web-enabled tool for
– Ease of use, wide involvement, quick responses
• Regular use tracks progress and measures changes
– Benchmarking against target maturity
62. SABSA Maturity Profile Process Areas
SMP Process Areas and SMP Process Activities
• Each of the six SMP domains is decomposed into
six SMP Process Areas
• These SMP Process Areas map onto the six cells
of the row of the SABSA
• Matrix corresponding to the particular SMP
domain
• The SMP Process Activities are then derived by
overlaying the SABSA
• Service Management Matrix onto the SMP
Process Areas
66. Architecture Measurement Categories
• Completeness
– Do we have all of the
components?
– Do they form an integrated
system?
• Assurance
– Does the system run
smoothly?
– Are we assured that it is
properly assembled?
– Is the system fit-for-purpose?
• Compliance
– Do we maintain the system?
– Do we follow the architecture
roadmap
– Do we comply with the rules?
• Performance
– Is the system properly tuned?
– Do the components work
together?
– Do we operate the system
correctly?
• Justification & significance
– Does the system have
business value?
67. Measurement Approaches
• High level statements of the approach to
obtaining a measurement
• Appropriate to the business need
• In the language of the intended audience
• Culturally specific
68. Measurement Guidelines
• Measurement should be a repeatable process
(for comparison & prediction)
• Measurement should have a clear
communications role
• Tracking performance
• Assigning resources
• Measurement should yield quantifiable metrics
(percentage, average, numbers, values, etc.)
69. Metrics Guidelines
• Data used to calculate metrics should be readily
obtainable
• Metrics may (should) be calculated
independently of parties with vested interest
• The type of metric used may change in line with
the maturity of the security process e.g. when
you are highly compliant, consider changing from
conformance measure to significance measure
• Performance metric / trend should be tested
prior to going ‘live’
• Expectations management is key
70. Types of Metric
• Soft Metrics
– Usually qualitative
– Subjective
– Open to interpretation and opinion (usually of the
authority setting the target or of an official
compliance agent such as a regulator or auditor)
• Hard Metrics
– Usually quantitative
– Objective
– Fixed, not open to opinion or interpretation
71. Types of Metric
• Descriptive
– Describes the current-state of the object / attribute
being measured
• Comparative
– Describes the current-state of the object / attribute
being measured in comparison with a similar object /
attribute relating to a different place and/or time
• Predictive
– Describes the current-state of the object / attribute
being measured in relation to its trend in order to
project and predict afuture state
Essentially started in 1987 with the publication of in the IBM Systems Journal of an article titled "A Framework for Information Systems Architecture," by J.A. Zachman where he laid out both the challenge and the vision of enterprise architectures that would guide the field for the next 20 years
U.S. DoD Technical Architecture Framework for Information Management (TAFIM) and was introduced in 1994 which had influenced creation of Clinger-Cohen Act of 1996 which was aimed at improving effectiveness of Govt. IT investments
Federal Enterprise Architecture Framework version 1.1 was released in 1999
FEAF renamed to FEA in 2002
TAFIM was retired in 1998 and the work done was turned over to The Open Group who morphed into what is today knows as TOGAF (The Open Group Architecture Framework)