Modelling Security Architecture

Modelling Security
Architecture
Narendra Ramakrishna
COSAC 2016
4th October 2016

S | E | A | M
Advisory and Consulting
Objective
 SABSA provides an excellent framework for business-driven Enterprise
Security Architecture and Design. Aspects such as business attributes
profile, domains and the trust modelling are something that the industry
has not witnessed in most other architecture frameworks. Although
there have been attempts to “model” security architecture with boxes,
lines, ellipses and circles, there is voidness in the area of modelling
enterprise security architecture that the industry could use and
potentially align with other architectural notations such as Archimate or
in the design land, UML.
 The intent of the paper is to propose a simple yet comprehensive
technique to model enterprise security architecture and design aligned
to SABSA that enables –
 Standardisation of SABSA Enterprise Security Architecture framework by formalizing
common language used in the form of ESA modelling notation
 Reusability of model artefacts (not documents) to enable enterprise and department
level collaboration and knowledge management
 Generic or organisation specific Library of assets for various ESA artefacts such as –
Business attribute profile(s), security services, mechanisms and components and
associated views
 Tool-assisted development using a separate toolbox for ESA that augments Enterprise
Architecture (ToGAF) modelling using Archimate
http://www.cosac.net/synopsis.html#2S

S | E | A | M
SABSA artefacts for
modelling security
architecture
 Model, Stakeholder Concerns and Viewpoints
 SABSA Meta-Model

S | E | A | M
Why a Modelling Notation for
SABSA?
Standardisation
ReuseContent Library
Standardisation enables
a common vocabulary
used in the form of SABSA
notation
Reusability of model
artefacts (not documents) to
reduce rework thereby
increasing throughput of
architecture and design
deliverables for business
projects
Enables generic or
organisation specific Library
of assets for various ESA
artefacts such as – Business
attribute profile(s), security
services, mechanisms and
components, domains and
associated views

S | E | A | M
5-minute overview of Model-View and
Viewpoints
Reference: ISO/IEC 42010:2011 - Systems and software engineering — Architecture description
’I am a CIO, I need to see
overview of the system to
present to the executive; don’t
give me the details‘
’I am a CEO, could you give me
a picture of how users would
use the system?‘
’I am a system designer, could I
get the interfaces that are
impacted?‘
’I am from operations, what
processes are you impacting?‘
CONCERN: Overview of impacted systems
CONCERN: Usage of the System
CONCERN: Impact on processes
CONCERN: System Architecture
Stakeholders and Concerns Viewpoints View (one or
more diagram)
Model
Repository
Deliverables

S | E | A | M
SABSA Meta-Model
Business Attribute
Approach to
derive business
drivers from
capabilities
Approach to
derive business
drivers from asset
register
Approach to
derive business
drivers from
business
requirement
We will see later
how this manifest
in reality

S | E | A | M
SABSA Meta-Model
SABSA Domain
Sub-domains
exists within a
domain
Trust
Relationships
could be
unilateral or
bilateral
Each domain
contains its own
Business Attribute
Profile

S | E | A | M
SABSA Meta-Model
Risk Model
Could be sourced
from popular
Threat
Intelligence
sources. STIX,
TAXI and CybOx
evolving as
popular formats
Control
Objectives from
ISF is used in our
case

S | E | A | M
SABSA Meta-Model
SABSA Controls
Process Model
might exist for
Physical and
Component Layers
also. Our case is
limited to Logical
Architecture.
The case makes
use of OSA
controls

S | E | A | M
Modelling Security
Architecture
 Key aspects of SABSA Modelled

S | E | A | M
Advisory and ConsultingExample Used: PSD/2 for Banks
 What is PSD/2?
 Extension to European Payments Service Directive with
significant changes
 Aspires to establish a level playing field for financial institutions
 Simplifies financial transactions for customers with use cases
such as unified accounts management, single payments
application etc. along with number of other use cases.
 Before and After PSD/2 – Account Information
Bank 1 App
Bank 1 App
Bank 1 App
BEFORE PSD/2
Third
Party
App
AFTER PSD/2 Accounting
Information Service
Providers [AISP]
https://openbankproject.com

S | E | A | M
Advisory and ConsultingExample Used: PSD/2 for Banks
 What is PSD/2?
 Extension to European Payments Service Directive with
significant changes
 Aspires to establish a level playing field for financial institutions
 Simplifies financial transactions for customers with use cases
such as unified accounts management, single payments
application etc. along with number of other use cases.
 Before and After PSD/2 – Payment Information
AFTER PSD/2BEFORE PSD/2
Acquirer
Card Payments
Service ProviderIssuer
Customer’s
Bank
Issuer
Customer’s
Bank

S | E | A | M
Are we modelling PSD/2
Architecture fully?
 This is for illustration ONLY
 The modelling reflects salient features of SABSA that
other notations don’t support out-of-box
 So, what are we modelling?
 Contextual Architecture – mainly uses Archimate 2.0 –
Motivation Extensions; we will do ‘Risk Modelling’
[Business Risks]
 Conceptual Architecture – key modelling illustrates
Business Attribute Profile, Control Objectives [Library] and
Domain modelling
 Logical Architecture – main focus is on Security Services,
alignment of Security Services with process modelling and
Trust Modelling

S | E | A | M
Our Setup for Modelling
Architecture
• Contextual
• Threats Catalogue
• Conceptual
• Business Attribute Profile
• Control Objectives
Library
• SABSA Domains
• Business
Attributes
• Risk Model
• Policy
Architecture
• Control
Objectives
• Sub-Domains
• Logical
• Security Services
• Security Mechanisms
• Security Components
PSD/2
Other Projects
External
Data
Sources
Reusable AssetsBusiness Projects
Effective Deployment is to
provision this on a Database
Views
(diagrams,
tables etc.)
Views
(diagrams,
tables etc.)
Project
Deliverables
Create
Views
Update
Assets
Sync
Assets

S | E | A | M
In the tool …
Business
Projects
Reusable
Assets
Example Import
from external
sources

S | E | A | M
Contextual Architecture
Mainly focusing on Risk Model [Threats]

S | E | A | M
SABSA – Contextual Layer
 Business Risk Model
Risk Model
Opportunities Threats Model
Threats
Inventory
Threat Scenario
Opportunities
Inventory
Opportunities
Scenario
• Threat Agents
• Relevant Threats
• …

S | E | A | M
In the tool …
Hierarchy as
per previous
slide
Modelling is NOT just
diagrams, diagram
elements and
relationships – it is
communication tool
expected to communicate
design intent with clarity.
If description is needed,
put it in the diagram
notes. It gets published
when documents are
published from the
model.
Master Threat
information
resides in
Reusable
Assets.
Frequent
updates to
threat
information
possible.
Reference: Threat Intelligence
Sharing using STIX and TAXII

S | E | A | M
Contextual Architecture
Other Views
Business Model [Assets] Business Capabilities [Process Inventory]
Organisation Structure [People] Business Geography [Location] Business Time Dependencies [Time]

S | E | A | M
Conceptual Architecture
Business Attributes Profile, Control Objectives and
Domains

S | E | A | M
Advisory and ConsultingBusiness Attribute Profile
Refer to meta-model slides between slides 5 and 8
It is a good idea to host ‘Business Attribute Profile
Template’ in reusable assets. All domains could use
it as a starting point.
Impacted Business Attributes
SABSA Properties of
Business Attributes
NOTE: The profile
provided with the
package need to be
imported into the tool
for these to appear.

S | E | A | M
Advisory and ConsultingTraceability from Contextual elements to
Business Attributes
If the relationships exist, they appear
when the elements are drag-and-
dropped into a diagram.
Trace relationship can produce
traceability in a tabular form.

S | E | A | M
Control Objectives
Control
Objective
Library – ISF
2016 SoGP
Control
Objectives
Principle and
Objective as
described by
ISF SoGP can
also be
imported
SoGP = Standard of Good Practice
Control Objectives
from any standards
could be imported

S | E | A | M
Advisory and ConsultingLinking Control Objectives to Business
Attributes
Tags are the best way
to specify additional,
context-specific
information without
impacting model
integrity.
However, tooling
vendors seems to
support tags in
multiple ways.
Trace relationships
could automatically
provide relationship
matrix [tool
dependent].

S | E | A | M
Advisory and ConsultingSABSA Domain – As container
So far, reusable assets just held catalogues. SABSA domains provides the first view
of Reusable Reference Architecture contextualised to a specific organisation.

S | E | A | M
Logical Architecture
Trust Model, Security Services and Usage of Security
Services

S | E | A | M
Trust Model
Functional Interactions Trust expressed through usage of Business Attributes and
Trust Relationships
Work in progress in this area to develop a better SABSA notation

S | E | A | M
Security Services
Used in same spirit as SOA Services (one of the use cases)

S | E | A | M
Traceability
From business attributes to security services

Modelling Security Architecture

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Viewers also liked

Viewers also liked (16)

Similar to Modelling Security Architecture

Similar to Modelling Security Architecture (20)

Recently uploaded

Recently uploaded (20)

Modelling Security Architecture