The Security Overlay for the ArchiMate language focuses on extending the architectural layers and Motivation aspect to create a model-based framework for SABSA.
The Security Overlay for the ArchiMate langugae uses the inbuilt customization capabilities of the ArchiMate Specification to define a Security Overlay: a set of security profiles for existing ArchiMate elements, supplemented by a set of new stereotyped elements, to express security concepts.
安全描述层是一组针对现有 ArchiMate 元素的安全描述,并辅以一组新的模式化元素,用于表达安全概念。
Link https://sabsa.org/category/working-groups/modelling-sabsa-archimate/ is to the MSA Working Group (Modeling SABSA ArchiMate), it has one whitepaper but still in ArchiMate v2.01, you need to register as SABSA member to be allowed for downloading the resources. (Whitepaper is downloaded and can be read here)
From SABSA perspective, back to upper link https://sabsa.org/category/working-groups/, you may find four Working Group which ArchiMate is one of them, I’m putting them briefly as below and would be take time to explore others once we’ve done this ArchiMate one first:
ID | Working Group (SABSA) | Info & Updates |
---|---|---|
WG100 | Security Services Catalogue (SSC) | https://sabsa.org/category/working-groups/security-services-catalogue |
WG101 | SABSA Enhanced NIST Cybersecurity Framework (SENC) | https://sabsa.org/category/working-groups/sabsa-nist-csf/ |
WG102 | SABSA Attributes Catalogue (SABAC) | https://sabsa.org/category/working-groups/sabsa-attributes-catalogue/ |
WG103 | Modelling SABSA with ArchiMate (MSA) | https://sabsa.org/category/working-groups/modelling-sabsa-archimate/ |
SABSA Service Management Matrix can be shown as below:
High-level perspective of aligning of SABSA and ArchiMate frameworks is as below (Figure 05 in Guide):
The left are the horizontal view for SABSA in 5 layers, looks like ArchiMate misses one “Concept” layer, while there’s some other EA tooling may provide tailored meta-model that can fit the cross mapping.
Wierda recommended to partition the Architecture Description into three planes:
Base on SABSA Executive Summary Whitepaper, below is the SABSA MATRIX (Simplified):
ASSETS (What) | MOTIVATION (Why) | PROCESS (How) | PEOPLE (Who) | LOCATION (Where) | TIME (When) | |
---|---|---|---|---|---|---|
CONTEXTUAL ARCHITECTURE | Business Decisions | Business Risk | Business Processes | Business Governance | Business Geography | Business Time Dependence |
CONCEPTUAL ARCHITECTURE | Business Knowledge & Risk Strategy | Risk Management Objectives | Strategies for Process Assurance | Roles & Responsibilites | Domain Framework | Time Management Framework |
LOGICAL ARCHITECTURE | Information Assets | Risk Management Policies | Process Maps & Services | Entity & Trust Framework | Domain Maps | Calendar & Timetable |
PHYSICAL ARCHITECTURE | Data Assets | Risk Management Practices | Process Mechanisms | Human Interface | ICT Infrastructure | Processing Schedule |
COMPONENT ARCHITECTURE | ICT Components | Risk Management Tools & Standards | Process Tools & Standards | Personnel Management Tools & Standards | Locators Tools & Standards | Step Timing & Sequencing Tools |
SERVICE MANAGEMENT ARCHITECTURE | Service Delivery Management | Operational Risk Management | Process Delivery Management | Personnel Management | Management of Environment | Time & Performance Management |
Those 6 pillars are in the same terminology to Zachman Framework, see below for comparison (sequence is not same):
Audience Perspective | What | How | Where | Who | When | Why | Model Names |
---|---|---|---|---|---|---|---|
Executive Perspective | Inventory Identification | Process Identification | Distribution Identification | Responsibility Identification | Timing Identification | Motivation Identification | Scope Contexts |
Business Management Perspective | Inventory Definition | Process Definition | Distribution Definition | Responsibility Definition | Timing Definition | Motivation Definition | Business Concepts |
Architect Perspective | Inventory Representation | Process Representation | Distribution Representation | Responsibility Representation | Timing Representation | Motivation Repreventation | System Logic |
Engineer Perspective | Inventory Specification | Process Specification | Distribution Specification | Responsibility Specification | Timing Specification | Motivation Specification | Technology Physics |
Technician Perspective | Inventory Configuration | Process Configuration | Distribution Configuration | Responsibility Configuration | Timing Configuration | Motivation Configuration | Tool Components |
Enterprise Perspective | Inventory Instantiations | Process Instantiations | Distribution Instantiations | Responsibility Instantiations | Timing Instantiations | Motivation Instantiations | Operations Instances |
Inventory Sets | Process Flows | Distribution Networks | Responbility Assignments | Timing Cycles | Motivation Intentions |
ArchiMate Concepts | Risk & Security Context |
---|---|
Information domains are cited as an appropriate use of the Grouping element | describe as “a set of users, their information objects and a security policy” |
Driver | defined as “an external or internal condition that motivates an organization to define its goals and implement the changes necessary to achieve them” |
Assessment | specialized into Risk and Vulnerability |
Business Event | specialized into Threat and Loss Event |
Business Actor | specialized into Threat Agent |
Goal | specialized into Control Objective |
Principle | specialized into Business Policy |
Requirement | specialized inot Control Measure |
Grouping | specialized inot Risk Domain |
Relationship between Event (Threat Agent/Event) to Assessment (Vulnerability or Impact):
Relationship | Explanation |
---|---|
[Event]-(Influcing)->[Assessment] | Event is a relevant factor in making an Assessment |
[Event]-(Associating)->[Assessment] | Threat Agent/Event «exploits» Vulnerability |
[Event]<-(Associating)-[Assessment] | Loss Event «materializes» Risk |
Figure 06:
Figure 07:
Figure 08:
Basic Elements & Relationships | Detail |
---|---|
identifier | An identifier used to provide a globally unique reference for the element within the model. |
isAbstract | An isAbstract flag, set to false by default, indicating that an element cannot be instantiated; it must have a non-abstract specialization (visually, an abstract element name is displayed in Italics) |
Stereotype/stereotypeOf | Stereotype/stereotypeOf used to declare out-of-model specialization structurally, rather than having to parse the structure of the («sterettype») name format |
Cardinality | Cardinality indicators at the source and target ends of relationships are expressed in UML notation; i.e., n (exactly), n..m (range n to m), * (any) (the meaning of the cardinality varies with context) |
Any comments, feel free to post to the Discussion Board.