ArchiMate_SABSA

09 Modeling the Physical Security Architecture

• 09 Modeling the Physical Security Architecture
  • 9.0 Physical Overview
    • Table 38: Physical Matrix in Ontology View
    • Table 39: Component Matrix in Ontology View
    • Figure 64: Developing SABSA Physical Security Architecture
  • 9.1 Data and Technology Assets
    • 9.1.1 Artifact
      • 9.1.1.1 Executable
      • 9.1.1.2 Data
      • 9.1.1.3 Configuration
    • 9.1.2 Device and Node
  • 9.2 Risk Management Practices
    • 9.2.1 Defect
  • 9.3 Process Mechanisms
    • 9.3.1 Technology Functions and Services
    • 9.3.2 System Software
  • 9.4 Human-Mechine Interfaces
    • 9.4.1 Technology Interface
  • 9.5 Physical Environment
  • 9.6 Timing and Interrupts
    • 9.6.1 Technology Security Events

9.0 Physical Overview

Table 38: Physical Matrix in Ontology View

Physical Artifacts:

Assets (What)	Motivation (Why)	Process (How)	People (Who)	Location (Where)	Time (When)
Data Assets	Risk Management Practices	Process Mechanisms	Human Interface	Infrastructure	Processing Schedule
- Dictionary & Data Storage - Devices Inventory	- Risk Management Rules & Procedures - Risk Metadata	- Working Procedures - Application Software - Middleware - Systems - Security Mechanisms Process Control Points	- User Interface to Business Systems - Identity & Access Control Systems	- Workspaces - Host Platforms, Layout of Devices & Networks	- Timing & Sequencing of Processes & Sessions

Physical Activities:

Assets (What)	Motivation (Why)	Process (How)	People (Who)	Location (Where)	Time (When)
Physical Asset Management	Risk Data Management	Operations Management	User Support	Resources Management	Performance Data Collection
- Change Management - Platform & Data Storage Management	- Risk Procedure Management - Risk Metadata Management	- Job, Incident, Event & Disaster Recovery Management	- Service Desk - Problem Management -Request Management	- Physical & Environmental - Security Management - Real Estate & Facilities Management	- Business Systems Monitoring - Procedure Management

Below we’re again using Protege to expand our SABSA Physical Architecture Matrix Ontology:

Snapshot Protege Ontology File: SABSA Matrics 2018 - Ch09 - Physical

Table 39: Component Matrix in Ontology View

Below we’re again using Protege to expand our SABSA Component Architecture Matrix Ontology:

Snapshot Protege Ontology File: SABSA Matrics 2018 - Ch08

Figure 64: Developing SABSA Physical Security Architecture

Snapshot ArchiMate Model: Figure 64: Developing the SABSA Physical Security Architecture

9.1 Data and Technology Assets

The principal Assets in this cell are the persisted formats of information/knowledge (applications and data) and IT infrastructure (hardware, system software, and network components).

The “bricks & mortar” type of physicla Assets are described in Section 9.5: Physical Environment

9.1.1 Artifact

In standard ArchiMate notation, Artifact serves as the universal passive structure element of the Technology Layer. It is overloaded to represent any kind of data object in the file system: executables, scripits, data and configuration files, databases, documents, specifications - everything in fact, except System Software.

The Security Overlay refines Artifact into sub-types that better reflect its different purposes and provides appropriate properties: see below Figure 65.

Snapshot ArchiMate Model: Figure 65: Stereotypes of Artifact

9.1.1.1 Executable

9.1.1.2 Data

9.1.1.3 Configuration

Snapshot ArchiMate Model: Figure 66: Configuration Files

9.1.2 Device and Node

Nodes represent a computational or physical resource that hosts, manipulates or interacts with other computational or physical resources.

Devices model physical IT resources (i.e., hardware) upon which system software and Artifacts may be stored or deployed for execution.

When modeling security infrastructure, it is sometimes useful to model nodes and devices having a specific security purpose as distinct stereotypes so taht role-specific properties can be assigned.

Below Figure 67 example shows a Hardware Security Module (HSM) being modeled as a stereotyped Device with properties that reflect FIPS-140-2 assurance levels and a VPN Gateway as a stereotyped Node with preperties that reflect the Common Criteria Evaluation Assurance Levels (EAL) for the protection profile of a type of product.

Snapshot ArchiMate Model: Figure 67: Stereotyping Security Nodes and Devices

9.2 Risk Management Practices

9.2.1 Defect

Software Defects are either published in product threat advisories, CVE (Common Vulnerabilities and Exposures, CVE.org) lists, or discovered in custom code.

The main exception to this is an organizataion’s process for approving deviations. Often there is legitimate business pressure for software to be deployed inot Production despite defects: a planned security control may not have been completed in time, or a penetration test has uncovereed a problem at the eleventh hour. In such circumstances, a decision must be made on risk. Models can be analyzed as “what if” scenarios to inform these risk decisions.

Below Figure 68 illustrates how highly relevant risk information is readily at hand:

Snapshot ArchiMate Model: Figure 68: Risk Management Practices

9.3 Process Mechanisms

From a security perspective, Technology Services fall into 2 main categories:

1. those that realize the security services identified in the conceptual layer, and
2. those that provide general platform services to Applications.

Below Figure 69 illustrates the pattern by which a conceptual security service, authentication, is realized by two distinct Technology Services: one which provides a single sign-on (SSO) capability for the organization domain, and the other, the local authentication mechanisms of a cloud application.

Snapshot ArchiMate Model: Figure 69: Realization of Security Services

Similar patterns can be deployed for other security services provided by the infrastructure:

• Security Incident Event Management (SIEM)
• Privileged Access Management Virus Scan
• Data Leak Prvention, and so on

The closed loops, including the invocation fo the conceptual Authentication service, its technical implementations and the services being protected, means that the model can not only verify that assurance strength requirements required by each Application Service are met, but also trace any Compliance requirements by identifying the closed loops described in Section 7.2.2.

Turning to Technology Services in general, while the ability to enforce access control is as important as the earlier analysis of Application Services, it is often mitigated by being co-located on the same Node, local network (Communication Network), or network domain. Priority should focus, therefore, on service invocations (调用) that originate outside trust domain boundaries.

9.3.1 Technology Functions and Services

Element	Schema File	Schema Visualization
Technology Service	Tech Srv JSON
Technology Process</br>Technology Function	Tech Proc & Func JSON

9.3.2 System Software

Element	Schema File	Schema Visualization
System Software	Tech Srv JSON

9.4 Human-Mechine Interfaces

9.4.1 Technology Interface

Element	Schema File	Schema Visualization
Technology Interface	Tech Int JSON

9.5 Physical Environment

9.6 Timing and Interrupts

9.6.1 Technology Security Events

Element	Schema File	Schema Visualization
«Executable»	Executable JSON
«Data»	Data JSON
«Defect» Service	Defect JSON

---

---

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

This site is open source. Improve this page.