Main points covered:
- the case for adopting a model -driven approach: the drivers & benefits of integrating security into EA models;
- the techniques / design patterns for expressing security within ArchiMate's notational & grammar constraints;
- a short demonstration of how these models can be used in practice
Presenter:
Steven is an independent consultant with 25+ years in IT. Based in Brussels, where he has undertaken major assignments for clients in the public sector, agencies, finance, telecoms and utilities and also lends his support to local cyber-security initiatives. Much of his work in recent years has been in the field of developing tools, processes and models to support security analysis.
Steven holds numerous security, architecture and privacy certifications including SABSA Chartered Practitioner and ArchiMate 3.0.
Date: August 28, 2019
Recorded webinar: https://www.youtube.com/watch?v=Bt1xRZQ5T58&t=3s
2. • What do we mean by ‘model’ and what are the benefits of modelling?
• Security Models – what are these?
• Evaluation of ArchiMate as a security modelling notation
- capabilities, limitations & tool support
• Modelling in Practice:
- practical steps
- examples
• Future Directions
Agenda
2
3. What is a Model?
• a simplified
representation
of a real-world
system …
• … that focusses
on the aspects
that matter
A
B
D
C
3
3
3
5
3
4. • Earlier, faster, cheaper, safer & more agile interaction than with real system
• Produces better architecture:
• Defers the selection of Solution Building Blocks
• Efficiencies:
27% cost, 30% time*
(40% cost, 50% time if testing included)
The Benefits of Model-Driven Engineering
4* Benefits of Model-based Development of Embedded Software Systems in Automobiles: Broy, Kirstan TU Munich
5. What is a Security Model?
5
• Attack Trees
• Threat Models
• Privacy Flow Diagrams
• Architectural Risk Diagrams
• Assets to be protected
• Entry and egress routes
• Data and control flows
• Attackers & their goals
• Placement of Controls
Various techniques currently in use
6. What do we require of a Security Model?
• Support all the tasks that
Security Analysts perform;
• Generate Artefacts from a
single underlying model
• Interactive Models
6
7. The Holy Grail: a “universal” Security Model
• Modelling Language
• Modelling Tools
Limited scope
Technical focus
No architectural layering
Informal notation
Constructive ambiguity
Just an annotated diagram
not machine readable
Nevertheless useful:
For common understanding
Focus for discussion
Any documentation is better than nothing!
7
8. Could ArchiMate provide a solution?
• Concise but expressive,
semi-formal notation;
• Layered core architecture;
• Capable of expressing intent -
Motivation & Strategy
• Standardised (TOG)
• Extensive tool support
• Extensible (within limits)
• Mature (v3.0 in 2017)
• Machine readable
• Widely adopted by other architects!
8
11. Modelling SABSA in ArchiMate
ArchiMate extensibility via:
• stereotyping of elements
• user-defined properties
• overloading relationships
• fewer constraints on relationships in v3.0
Obstacles & limitations:
• core language specification
• features provided by tools
Good news: It’s possible!
11
Details being prepared in a White Paper
Planned launch for COSAC 2019
12. Modelling Assets
12
• Security is concerned with the
protection of assets;
• ArchiMate has no concept of asset;
• 2018 SABSA Matrix shifts focus to
Business Value & Value Chains;
• ArchiMate has a Value Element ;
AssetValue
Asset
AssetValue AssetStakeholder
Value
Asset AStakeholder 1
Asset BStakeholder 2
Stakeholder 3AssetValue
AssetStakeholder
13. Principle
ArchiMate 3.0 Specification
Principle
“represents a qualitative statement of intent that
should be met by the architecture”
“defines a general property that
applies to any system in a certain context”
We need to talk about Attributes …..
ArchiMate has no concept of SABSA Business Attributes
13
14. Modelling SABSA Attributes as Principles
Goal PrincipleOutcome Requirement Constraint
14
Confidentiality
Protection of
Data at Rest
Protection of
Data in Transit
Access Control Channel Encryption
Confidentiality
Protection of
Data at Rest
Protection of
Data in Transit
Access Control Channel Encryption
Confidentiality
A
Protection of
Data at Rest
Protection of
Data in Transit
Access Control Channel Encryption
Confidentiality
B
Adopt design convention: SBAs only participate by “influence”
Limitation: Can’t be enforced inside the modelling tool
Confidentiality
Protection of
Data at Rest
Protection of
Data in Transit
Access Control Channel Encryption
+ ++
16. Goal Principle
Motivational
Element
+influences
associated with
Outcome Requirement ConstraintDriver
<<SABSA Business Attribute>>
<<Impact>>
<<Threat>> <<Vulnerability>>
<<Risk>>
Assessment
<<Opportunity>>
<<Control Objective>> <<Accept>>
<<Mitigate>> <<Transfer>>
<<Avoid>> <<Control>> <<Control>>
Value <<Value Chain>>Meaning
Stereotyping Core Elements
ArchiMate has no “Security elements”: Threat, Vulnerability, Risk etc.:
Limitation: << stereotype>> is just a naming convention! 16
17. Adding User-defined security properties
Users are free to add properties to ArchiMate concepts:
Limitations:
• simple key-value pairs
• no intrinsic support for data type, validation,
defaults, optional vs. mandatory
• Tool support varies
• no standardisation
Business
Information
17
18. Overloading Relationships
ArchiMate reuses relationship notations to mean different (but similar) things in different contexts:
18
Assignment
Business
Actor
Business
Role
Application
Component
Application
Function
Device System Software
Realisation
Requirement
Application
Process
Data Object
Application
Service
Goal
Artifact
Business
Information
Flow
Application
Process A
Application
Process B
data
Business
Actor A
Business
Actor B
trust?
Limitations:
• Sometimes the preferred relationship is not legal
• Compromises sometimes required in choice of element or relationship
19. ArchiMate 2
Business
Actor
Business
Process
Business
Service
Application
Service
Infrastructure
Service
Application
Function
Infrastructure
Function
Fewer Relationship Constraints
ArchiMate relationships less constrained by layers and directionality:
Limitations:
• The preferred relationship is not always legal
• Workarounds required in choice of element or relationship
19
ArchiMate 3
Business Actor Business Role
Identity
Access Rights
<<Principal>> <<Authorisation>>
Conceptual
Logical
<<Account>>
Contextual
<<Application Role>>
Business Actor Business Role
Identity
Access Rights
<<Principal>> <<Authorisation>>
Conceptual
Logical
<<Account>>
Contextual
<<Application Role>>
20. Conclusions so far:
• Possible to express security concepts in ArchiMate
…. but work intensive!
• Properties & stereotypes are ‘decoration’:
– 2nd class aspect of the language
– no schema
– limited tool support
– no standardisation
• Good for generating documentation
→No validation of completeness, consistency, validity etc
….
Making Life Easier
ArchiMate
Security-Enhanced
20
But what about the
ArchiMate
Exchange Format?
Exchange Format
Transform Validate
23. Q&A
The SABSA Institute
Further information
• The SABSA Institute:
• ArchiMate Security Overlay
• SABSA Matrix Artefacts in ArchiMate
• COSAC Ireland (Oct 2019):
• Tools & Methodology Interest Group
• Workshop: Security Modelling in ArchiMate
• COSAC Melbourne (Dec 2019):
• Have You Ever Considered Modelling?
24. ISO/IEC 27032
Training Courses
• ISO/IEC 27032 Introduction
1 Day Course
• ISO/IEC 27032 Foundation
2 Days Course
• ISO/IEC 27032 Lead Cybersecurity Manager
5 Days Course
Exam and certification fees are included in the training price.
www.pecb.com/en/education-and-certification-for-individuals/iso-iec-27032
www.pecb.com/events