Enterprise Security Architecture was initially targeted to address two problems 1- System complexity 2- Inadequate business alignment Resulting into More Cost, Less Value

1. Enterprise Security Architecture
Arnab Chattopadhayay
Vice President, Engineering
Infoworks Inc.

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

3. Enterprise Architectural Methodologies
• Consortia-developed Frameworks
– ISO 19439
– RM-ODP (ITU-T X.901-904)
– TOGAF
• Defense Industry Framework
– DoDAF
– MODAF
– NAF
• Government Framework
– ESAAF
– FEAF
– NIST Enterprise Architecture Model
• Open Source Frameworks
– TRAK
– SABSA
• Proprietary Frameworks
• Zachman Frameworks
• IAF (Capgemini, 1993)

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

7. Zachman Framework (4)
Source: zachmaninternational.com
[Executive Mgmt
Perspective]
[Business Mgmt
Perspective]
[Architect’s
Perspective]
[Engineer’s
Perspective]
[Technician’s
Perspective]

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

14. Features and Advantages
Feature Advantage
Business Driven Value-assured
Risk Focused Prioritized and proportional responses
Comprehensive Scalable scope
Modular Agility – ease of implementation and
management
Open Source (protected) Free use, open source global standard
Auditable Demonstrate compliance
Transparent Two-way traceability
©SABSA Foundation 2010

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)

18. ©SABSA foundation, 2010
Logical
Process Maps
& Services
Domain Maps
Entity & Trust
Framework
Calendar &
Timetable
Physical
ICT
Infrastructure
Human
Interface
Processing
Schedule
Component
Locator
Tools &
Standards
Personnel
Management
Tools & Standards
Step Timing
& Sequencing
Tools
Service
Management
Service
Delivery
Management
Process
Delivery
Management
Management of
Environment
Personnel
Management
Time &
Performance
Management
Information
Assets
Data
Assets
ICT
Components
Process
Mechanisms
Process Tools
& Standards
Assets
(What)
Process
(How)
Location
(Where)
People
(Who)
Time
(When)
Contextual
Business
Decisions
Business
Processes
Business
Geography
Business
Governance
Business
Time
Dependence
Conceptual
Business
Knowledge &
Risk Strategy
Strategies for
Process
Assurance
Domain
Framework
Roles &
Responsibilities
Time
Management
Framework
Motivation
(Why)
Business
Risk
Risk
Management
Objectives
Risk
Management
Policies
Risk
Management
Practices
Risk Management
Tools &
Standards
Operational
Risk
Management
SABSA Matrix

19. SABSA Lifecycle
Business View Contextual Architecture
Architect’s View Conceptual Architecture
Designer’s View Logical Architecture
Builder’s View Physical Architecture
Tradesman’s View Component Architecture
Service Manager’s View Operational Architecture

20. SABSA Mapping with other Security Standards
Applications
Presentation
Session
Transport
Network
Link
Physical
Applications
Presentation
Session
Transport
Network
Link
Physical
ISO 7498-1 ISO 7498-2
Logical
Security
Services
Physical
Security
Mechanisms
Contextual Architecture
Conceptual Architecture
Business
Driven
Requirements
& Strategy
SABSA Views
Logical Architecture
Physical Architecture
Component Architecture
Operational Architecture Service
Management
Detailed
Custom
Specification

21. Bringing All Together
BusinessStrategy
Goals
Relatio
nship
Market
Regula
tion
People
Materi
als
Financ
e
Produc
tion
Logisti
cs
BAP
Risk
Model
Trust
Model
SecurityStrategy
Process
Design
Policy & Legal
Framework
Technical
Design
LogicalSecurityServices
Confidentiality
Identification
Registration
Certification
Directories
Authentication
Authorization
Access Control
Audit Trail
PhysicalSecurityMechanism
Encryption
Naming
Procedures
Signatures
Databases
Passwords
ACLs
Firewalls
Event Logs
Components
TrustedBusinessOperations
ProductsTools

22. Using SABSA
Define
Contextual
Security
Architecture
Define
Conceptual
Security
Architecture
Define Logical
Security
Architecture
Define
Physical
Security
Architecture
Define
Component
Security
Architecture
Define Operational Security Architecture

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

24. BUSINESS CONTEXT AND
REQUIREMENTS
Framework

25. Scope: Strategy & Planning Phase -
Assets

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

31. Two-way Traceability – Drivers to
Attributes

32. Two-way Traceability – Attributes to
Drivers

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

35. BUSINESS CONTEXT AND
REQUIREMENTS
Implementation Approach

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

38. ARCHITECTURAL STRATEGIES

39. Scope: Strategy & Planning Phase -
Process

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

41. Strategy & Planning Phase Alignment

42. Risk Management Method Alignment

43. Performance & Reporting Methods

44. Control Objectives Libraries &
Standards

45. Controls Frameworks & Libraries

46. SABSA Multi-tiered Control Strategy

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

48. Application of SABSA Multi-tier Control

49. Application of Multi-tiered Control Strategy

50. PLANNING & PERFORMANCE
MANAGEMENT CONCEPTS

51. Scope: Strategy & Planning Phase -
Time

52. Architecture Strategy & Planning Phase

53. Architecture Design Phase

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)

56. Manage & Measure Phase – SSM Matrix

57. SABSA Development Process

58. SABSA Risk Management Process Overview

59. Risk Management and the SABSA Matrix

60. SABSA Lifecycle Domain Risk Perspectives

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

63. SMP Maturity Levels

64. SMP Generic Practices

65. Performance Management Framework
Defining Business-driven Performance Targets

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

72. Conceptual Measures & Metrics Framework

73. SABSA Vitality Framework

74. Thank You