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
Advisory and Consulting
SABSA artefacts for
modelling security
architecture
 Model, Stakeholder Concerns and Viewpoints
 SABSA Meta-Model
S | E | A | M
Advisory and Consulting
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
Advisory and Consulting
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
Advisory and Consulting
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
Advisory and Consulting
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
Advisory and Consulting
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
Advisory and Consulting
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
Advisory and Consulting
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
Advisory and Consulting
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
Advisory and Consulting
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
Advisory and Consulting
In the tool …
Business
Projects
Reusable
Assets
Example Import
from external
sources
S | E | A | M
Advisory and Consulting
Contextual Architecture
Mainly focusing on Risk Model [Threats]
S | E | A | M
Advisory and Consulting
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
Advisory and Consulting
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
Advisory and Consulting
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
Advisory and Consulting
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
Advisory and Consulting
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
Advisory and Consulting
Logical Architecture
Trust Model, Security Services and Usage of Security
Services
S | E | A | M
Advisory and Consulting
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
Advisory and Consulting
Security Services
Used in same spirit as SOA Services (one of the use cases)
S | E | A | M
Advisory and Consulting
Security Services
Used in same spirit as SOA Services (one of the use cases)
S | E | A | M
Advisory and Consulting
Traceability
From business attributes to security services

Modelling Security Architecture

  • 1.
  • 2.
    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
  • 3.
    S | E| A | M Advisory and Consulting SABSA artefacts for modelling security architecture  Model, Stakeholder Concerns and Viewpoints  SABSA Meta-Model
  • 4.
    S | E| A | M Advisory and Consulting 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
  • 5.
    S | E| A | M Advisory and Consulting 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
  • 6.
    S | E| A | M Advisory and Consulting 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
  • 7.
    S | E| A | M Advisory and Consulting 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
  • 8.
    S | E| A | M Advisory and Consulting 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
  • 9.
    S | E| A | M Advisory and Consulting 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
  • 10.
    S | E| A | M Advisory and Consulting Modelling Security Architecture  Key aspects of SABSA Modelled
  • 11.
    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
  • 12.
    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
  • 13.
    S | E| A | M Advisory and Consulting 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
  • 14.
    S | E| A | M Advisory and Consulting 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
  • 15.
    S | E| A | M Advisory and Consulting In the tool … Business Projects Reusable Assets Example Import from external sources
  • 16.
    S | E| A | M Advisory and Consulting Contextual Architecture Mainly focusing on Risk Model [Threats]
  • 17.
    S | E| A | M Advisory and Consulting SABSA – Contextual Layer  Business Risk Model Risk Model Opportunities Threats Model Threats Inventory Threat Scenario Opportunities Inventory Opportunities Scenario • Threat Agents • Relevant Threats • …
  • 18.
    S | E| A | M Advisory and Consulting 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
  • 19.
    S | E| A | M Advisory and Consulting Contextual Architecture Other Views Business Model [Assets] Business Capabilities [Process Inventory] Organisation Structure [People] Business Geography [Location] Business Time Dependencies [Time]
  • 20.
    S | E| A | M Advisory and Consulting Conceptual Architecture Business Attributes Profile, Control Objectives and Domains
  • 21.
    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.
  • 22.
    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.
  • 23.
    S | E| A | M Advisory and Consulting 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
  • 24.
    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].
  • 25.
    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.
  • 26.
    S | E| A | M Advisory and Consulting Logical Architecture Trust Model, Security Services and Usage of Security Services
  • 27.
    S | E| A | M Advisory and Consulting 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
  • 28.
    S | E| A | M Advisory and Consulting Security Services Used in same spirit as SOA Services (one of the use cases)
  • 29.
    S | E| A | M Advisory and Consulting Security Services Used in same spirit as SOA Services (one of the use cases)
  • 30.
    S | E| A | M Advisory and Consulting Traceability From business attributes to security services