ArchiMate_SABSA

05 The Motivation Aspect

A quick table shows the ArchiMate notations matching SABSA attributes:

SABSA	ArchiMate Notation
Value / Loss / Value Chain	Value
Business Attribute / Article / Mandate / Trust	Principle
Control Objective / Compliance Objective	Goal
Controls* / Exception	Requirement
Context of Requirements	Meaning
Risk / Impact / Threat / Vulnerability	Assessment
Constraint	Constraint
Standard / Regulation	Representation

* Control is unique in the Security Overlay in that it can extend any base type.

Figure 10: Security Enhanced Motivation Metamodel

• Image:
• Archi Model: ArchiMate_SABSA_Figure10.archimate

5.1 Value & Loss

The “What” column of the SABSA Architecture Matrix acknowledges the business value of assets.

Business Value may be expressed in several forms (financial, legal, brand, social, economic, health & safety) in combination or with others.

This evolution brings it closer to the ArchiMate Specification, which has no element to represent an abstract Asset but instead offers the ability to associate a Value element with any model element.

Figure 11: Modeling Assets using Value

Models containing many Values will have following consideration for reflecting the associated Element name through adopting of a naming conversion:

Figure 11	Diagram	Source
a) Simple model, shows the simple association of a Value with a generic eelment, thereby making it as an asset.		11-a
b1) Modeling Value to Stakeholder, this model needs CAUTION when a Value is appreciated by several Stakeholder or associated with multiple assets.		11-b1
b2) Modeling Value to Stakeholder, this in-line (teritiary) relationship is better pattern and is recommended		11-b2
c) Avoice this kind of Amibiguity/Unintended Coupling		11-c

For 11-b2, here is the updated code for diagramming, after checking with PlantUML team:

@startuml
title Figure 11 - b)-2 Modeling Value to Stakeholder (Recommended)

class Stakeholder <<motivation>>
class AssetValue <<motivation>>
class Asset <<element>>

hide <<motivation>> circle
hide <<element>> circle

hide <<motivation>> members
hide <<element>> members

Stakeholder - Asset
AssetValue .. (Stakeholder, Asset)

@enduml

Fullying using Class Diagram notations with the link to the link:

Table 10: Proposed Value Property Overlay

Visualized Schema for Element Value / «Loss» is modeled in JSON format: Value_Loss.json

5.2 Value Chain

Figure 12: Composition of Value Chain

The Security Overlay also specializes Value into «Value Chain», providing a specific profile for the Strategy elements, Capability and Value Stream.

Detail is to be discussed in Chapter 6.1

• The key measures of meta-processes are rooted in cost-accounting: production cost, sales prices, and margin.
• The organization seeks to identify which activities generate value and which are inefficient or uneconomic.
• The security perspective is concerned with enhancing and protecting the value of the value generators while containing the costs of the inefficient process.
• The ValueChain stereotype models the breakdown of costs and is, therefore, principally a financial measure.

• The Security Overlay can be used to map the composition of a Value Chain to any behavioral element in the Enterprise Architecture model.

• Image:
• Archi Model: ArchiMate_SABSA_Figure12.archimate

Table 11: Value Chain Properties

• The attributes proposed for the Value Chain profile enable the margin to be calculated as the sum of its constituent sub-chains.
• The ArchiMate Specification allows the Value elements to be decomposed into compositions and aggregations of the same type.
• Composition seems the safer option here because, unlike aggregation, it should prevent cost accounting figures from being counted multiple times.

Check here for the JSON format Schema on Value Chain properties.

5.3 SABSA Business Attributes

Figure 13: SABSA Business Attributes Represented in the ArchiMate Language

SABSA	ArchiMate
Business Attributes represent the essential qualities of the Stakeholders’ ideal system, to be promoted, protected, and enhanced in the Target Architecture if the enterprise is to deliver its strategy.	Principle elements are defined as “an intended property of a system … a general property that applies to any system in a certain context … motivated by some goal or driver”

Memo:

1. Business Attribute is modelded as a specialization of Principle, distinguishing it from convertional uses (such as “Cloud First”) and enabling it to define a distinct security profile
2. The taxonomy is structured as an abstract base Business Attribute, specialized into domains using Groupings
   • Domains act as namespaces that support the construction of qualified names enabling Attributes to be overloaded with an appropriate definition and metrics for different contexts
   • Grouped attributes promote consistency and correctness in modeling; e.g., Stakeholders with legal concerns should only be offerted associations with Legal and Regulatory attributes
   • It enables Attributes with the same non-qualified name to appear on the same diagram

Here, you can access the free part of this book - Enterprise Security Architecture: A Business-Driven Approach, I put downloaded PDF for your convenience.

Snapshot ArchiMate Model: ArchiMate_SABSA_Figure13.archimate

Table 12: SABSA Attribute Properties

«SABSA Attribute» JSON Schema

5.3.1 Structural Placement of Business Attributes

Figure 14: Hierarchy of Abstraction

Abstraction level from top to bottom:

1. Principle: a fundamental, primary, or general law or truth from which others are derived.
2. Policy
3. Control Objective
4. Control Requirement (and Constraints)

Figure 15: The SWIFT/COSO Model

• 3 Objectives
• 8 Principles
• 27 Controls

The original 20024 COSO Enterprise Risk Management framework (https://www.coso.org/enterprise-risk-management) placed “Principles” between “Objectives” and “Controls”.

Figure 16: Principle in the ArchiMate Motivation Hierarchy

The ArchiMate Specification follows the COSO paradigm, putting Principles to be used as maxims to guide Designers toward Outcomes and Goals.

Snapshot ArchiModel File: Model-Figure16

Figure 17: Highlighting the Control Hierarchy Mismatch (i)

What SABSA Would Like to Express	What ArchiMate Specification Supports
Attribute (Confidentiality) as being satisfied by specific Goals (“Protections of Data at Rest” and “Protection of Data in Transit”) at various points in the model. These are to be achieved by distinct, verifiable Requirements (“Access Control” and “Channel Encryption”), respectively.	Place Confidentiality in the center of the structure and, by doing so, forces the realization paths to merge. The resulting model suggests “Protection of Data at Rest” might be realized through “Channel Encryption” and “Protection of Data in Transit” through “Access Control”.

The result is both unintentional and incorrect. It is also difficult to disentangle because, even if the structures are drawn as distinct views, they remain merged in the underlying model, causing a problem for automated analysis which sees both paths as legitimate and is consequently unable to resolve the modeler’s intent.

Snapshot ArchiModel File: Model-Figure17

Figure 18: Highlighting the Control Hierarchy Mismatch (ii)

A workaround might be parallel stacks (Below right), each with its own instance of “Confidentiality”.

What SABSA Would Like to Express	What ArchiMate Specification Supports
	Note these need to be distinct elements (with distinct names) to avoid the entanglement of the previous proposal.

Although this approach achieves the required segregation and is entirely within the specification, creating distinct Confidentiality elements for each stack is inelegant.

Conceptually, Attributes are singletons, so any duplication creates redundancy and maintenance issues.

If a good model is meant to reflect reality, this is a poor style: the concept of different “flavors” of confidentiality is not a natural way to model the real world.

Snapshot ArchiModel File: Model-Figure18

Figure 19: Achieving the Desired Hierarchy

This is a better solution eschews the standard structure, but remains legal and reflects the original intent.

What SABSA Would Like to Express	What ArchiMate Specification Supports
	Via a convertion in which SABSA Attributes are only ever influence by Control Objectives, the desired structure can be achieved within legal grammer.

This choice aligns with the ArchiMate definition of influence as “a traceable motivational path”, where the “motivation element is achieved to a certain degree”. That is to say, SABSA Attributes are strengthened by the achievement of Control Objectives rather than attained absolutely.

Snapshot ArchiModel File: Model-Figure19

5.3.2 Traceability of Business Attributes

This is another essential requirement of SABSA Attribute modeling, which is the ability to trace their refinement through the architectural layers, also implemented using influence relationships, see below Figure 20.

Figure 20: Attribute Traceability Across Layers

Because SABSA Attributes are global singletons, reuse within a model runs the risk of unintended coupling.

Snapshot ArchiModel File: Model-Figure20

5.4 Meaning

The ArchiMate Meaning element is not extended by the Security Overlay other than by the addition of an optional profile.

As described in the previous sections, the SABSA Attribute taxonomy incorporates a catalog of elements, definitions and hard/soft metrics via the security profile.

Because Business Attributes are modeled as singletons, any definition and metric, modeled within the profile, will apply to everything that the Attribute touches; i.e., in every context where the Attribute is referenced.

Figure 21: Applying Attribute Metrics to Multiple Controls

This causes problems where an Attribute is applied to multiple points in the same model. Consider, for example, whether there is a single Confidentiality Attribute enhanced by the two Control Objectives and four Controls of Figure 21. How can be express context-sensitive definition and metrics?

Figure 21: Applying Attribute Metrics to Multiple Controls (Snapshot Model: Model-Figure21)

Figure 22: Use of Meaning of Externalize Context-Sensitive Metrics

The Security Overlay recommends the use of Meaning elements to re-interpret the Attribute for each context.

Figure 22 shows how the meaning of Confidentiality (i.e. definition and metrics) can be externalized and then adapted to Tokenization, Access Control, and other requirements using Meaning elements. (Snapshot Model: Model-Figure22)

5.5 Impact, Threat, Vulnerability, and Risk

Guided by the ArchiMate Specification, impacts, threats, vulnerabilities, and risks are modeled as stereotyped __Assessment__ elements, providing a good semantic fit that reflects the subjective uncertainty inherent in assessing these unknowns.

Table 13: Risk Element Properties

Element	Schema File	Schema Visualization
«Risk»	Risk JSON
«Impact»	Impact JSON
«Threat»	Threat JSON
«Vulnerability»	Vulnerability JSON

5.6 Controls: Objectives, Requirements, and Measures

In ArchiMate Specification, Goal is specialized as Control Objective, and Requirement is specialized as Control Measure.

To cope with the semantic question, the Security Overlay retains the «Control Objective» stereotype of Goal, retains Requirement for security requirements without specialization, and introduces a new «Control» stereotype to represent the control mechanism.

Figure 23: Expressing Composite Requirements

Modeling a Control Objective realized by a control mechanism via a requirement is a good semantic fit. In practice, though, a single Requirement is often insufficient.

Snapshot Model: Model-Figure23

Figure 24: Example of a Control Pattern

Sometimes a requirement is realized through a combination of elements and relationships, acting in concert. In such cases, the realization of the requirement can be expressed as a pattern using a grouping marked as a control stereotype.

Snapshot Model: Model-Figure24

5.7 Multi-Teired Security

SABSA’s Conceptual/Process cell discusses the combination and layering of Controls for “Defense-in-Depth” or “End-to-End Protection”.

The Blue Book (Enterprise Security Architecture - A Business-Driven Approach, preview link) describes a 4-tier model:

• Prevent
• Contain
• Detect & Notification, and
• Recovery & Restoration.

The NIST™ Cybersecurity Framework (local download link: NIST CyberFramework 2.0) identifies six control functions:

• Govern
• Identify
• Protect
• Detect
• Respond, and
• Recover

Table 14: Control Element Properties

The Security Overlay:

• adds the category “Deter” to cover sanctions expressed in Policies & Contractual clauses.
• the identify set (including Asset Management, Business Environment, Governance, Risk Assessment, and Risk Management Strategy) are modeled in the 2nd and tertiary (3rd, 第三) architectures rather than the primary, run-time architecture.
• the profile for the Control elements has been derived from analysis and use of several commonly used control frameworks.

Element	Schema File	Schema Visualization
Control Element	ControlElement

Figure 25: Example of Multi-Tiered Security

In this Figure 25, profile attributes are declared in the Control Objectives element to define its protection requirement and in each Requirement element to describe its protection capability.

Snapshot Model: Model-Figure25

Compliance

The “Why” cells of Contextual and Conceptual cells address the important and demanding driver.

The Security Overlay has been extended with additional stereotype to support the representation of Compliance Objectivess and guidance on managing the complexity created by the challenges of simultaneous multi-regulatory compliance.

5.8 Regulations and Standards

Compliance controls are defined in public standards:

• Some are mandatory carrying the force of laws
• Some are pre-requisite for a license to operate
• Others may be important in demonstrating good governance, fulfilling market expectations or measuring capability maturity.

Figure 26: The Structure of Standards and Regulations

«Standard» documents:

• ISO27001: Local Copy1, Local Copy2
• NIST SP 800-53: Online Link

Snapshot Model: Model-Figure26

Table 15: Standard and Regulation Properties

Element	Schema File	Schema Visualization
«Regulation»	Regulation

5.9 Articles, Mandates, and Compliance Objectives

Legal texts tend to consist of articles (schedules), paragraphs, and clauses, numbered for cross-reference.

Articles serve multiple purposes:

• they can be used to define terminology
• they can be used to assert scope and applicability
• they can be used to cite mandates that empower the issuing body with authority to act in the given domain

Only after considerable preamble (序言) do the Articles generally turn to address what needs to be accomplished. Articles consist of paragraphs and sub-paragraphs that are eventually built form short, well-focused clauses.

To model this in ArchiMate language, the Security Overlay draws an equivalence between legal paragraphs and Compliance Objectives (an analog of the risk-based Control Objective) and between legal clauses and Requirements/Constraints.

Figure 27: Articles and Compliance Objectives

To model the Articles themselves: as with SABSA Attributes, we need to represen an abstract concept, the law, an ideal to be pursued in letter and in spirit by meeting specific, achievable goals. The Security Overlay turns to a stereotype of Principle, «Article» - and the convention of only referencing it through influence relationships.

Snapshot Model: Model-Figure27

This same 3-tier pattern (Concept-Goal-Requirement) is also evident in sectoral and technical standards. While the stereotypes already are re-usable at the Goal1 and Requirement levels, neither the «SABSA Attribute» nor «Article» are intuitive names for the top-level concepts found in these standards.

Table 16: Compliance Conceptual Element Properties

Element	Schema File	Schema Visualization
«Article» & «Mandate»	Article & Mandate JSON
«Compliance Objective»	Compliance Objective JSON
«Exception»	Exception JSON

5.10 Control Mechanisms

Three fundamental elements for modeling a control architecture are:

• An abstract concept of an ideal that is being pursued, e.g. SABSA Attribute, a statute of regulatory (Article) or standards (Mandate) compliance, modeled as a stereotype of Principle
• A specific, realizable, defined state of a system component that represents a sufficient realization of the ideal if achieved, maintained, and evidenced. These are modeled as Control Objectives and Compliance Objectives, stereotypes of Goal.
  • The architecture will aim for this state by a given date.
  • The emphasis is on brining a risk within appetite or demonstrating compliance with the law at an acceptable cost and schedule.
  • Objectives are not aiming for the achievement of perfection.
• Control Requirements, Constraints, and Exceptions specifying granular actions and restrictions that, when performed in the right way, in the right place, at the right time, and for the right cost, achieve the overall objective.

Figure 28: Use Cases and Iconography for Control

This figure confirms that real-world Controls manifest in many forms.

Snapshot Model: Model-Figure28

What can be concluded from this set of examples are:

• Controls are often a component of an element of the same type
• Control stereotypes cannot be formed from a single base type but require multiple base types

Table 17: Control Properties

Element	Schema File	Schema Visualization
«Control»	Control JSON

5.11 Trust

Trust in Security Overlay is another stereotype of Principle. The element enables the explicit modeling of any trust implicit in an interaction between Parties.

The definition given here will be discussed on its usage until Section 6.4.1.

Table 18: Trust Profile

Element	Schema File	Schema Visualization
«Trust»	Trust JSON

---

---

Any comments, feel free to post to the Discussion Board.

This site is open source. Improve this page.