Integrating Risk and Security within a TOGAF® Enterprise Architecture

The TOGAF® Standard

---

Provide feedback on this page

---

Table of Contents

Preface

1 Introduction

1.1 How does this Guide Support the TOGAF Standard?

1.2 What about Risk Management?

1.3 Where is the Controls Checklist?

2 Relationship to Other IT Security and Risk Standards

2.1 ISO/IEC 27001:2013: Information Security Management

2.2 ISO 31000:2009: Risk Management – Principles and Guidelines

2.3 National Cybersecurity Frameworks

2.4 COBIT®

2.5 O-ESA

2.6 O-ISM3

2.7 Open FAIR

2.8 SABSA®

3 Enterprise Security Architecture

3.1 Enterprise Risk Management

3.1.1 Definition of Risk

3.1.2 Core Concepts for Enterprise Risk Management

3.2 Information Security Management

3.2.1 Security

3.2.2 Privacy

3.2.3 Core Concepts for Information Security Management

3.2.4 Operational Security Processes

4 Security as a Cross-Cutting Concern

5 Security and Risk Concepts in the TOGAF ADM

5.1 Preliminary Phase

5.1.1 Business Drivers/Business Objectives

5.1.2 Security Principles

5.1.3 Risk Appetite

5.1.4 Key Risk Areas/Business Impact Analysis

5.1.5 Security Resource Plan

5.2 Phase A: Architecture Vision

5.3 Phase B: Business Architecture

5.3.1 Security Policy Architecture

5.3.2 Security Domain Model

5.3.3 Trust Framework

5.3.4 Risk Assessment

5.3.5 Business Risk Model/Risk Register

5.3.6 Applicable Law and Regulation Register

5.3.7 Applicable Control Framework Register

5.4 Phase C: Information Systems Architectures

5.4.1 Security Services Catalog

5.4.2 Security Classification

5.4.3 Data Quality

5.5 Phase D: Technology Architecture

5.6 Phase E: Opportunities and Solutions

5.6.1 Risk Mitigation Plan

5.7 Phase F: Migration Planning

5.8 Phase G: Implementation Governance

5.8.1 Security Audit

5.8.2 Security Training and Awareness

5.9 Phase H: Architecture Change Management

5.10 Requirements Management

5.10.1 Business Attribute Profile

5.10.2 Control Objectives/Security Objectives

5.10.3 Security Standards

5.11 The TOGAF Architecture Content Metamodel

5.12 Use of the ArchiMate® Modeling Language

1 Introduction

Enterprise Architecture (including Security Architecture) is all about aligning business systems and supporting information systems to realize business goals in an effective and efficient manner (systems being the combination of processes, people, and technology). One of the important quality aspects of an Enterprise Architecture is information security and the way this can be managed. For too long, information security has been considered a separate discipline, isolated from the business processes and Enterprise Architecture.

A Security Architecture is a structure of organizational, conceptual, logical, and physical components that interact in a coherent fashion in order to achieve and maintain a state of managed risk and security (or information security). It is both a driver and enabler of secure, safe, resilient, and reliable behavior, as well as for addressing risk areas throughout the enterprise.

However, an Enterprise Security Architecture does not exist in isolation. As part of the enterprise, it builds on enterprise information that is already available in the Enterprise Architecture, and it produces information that influences the Enterprise Architecture. This is why a close integration of Security Architecture in the Enterprise Architecture is beneficial. In the end, doing it right the first time saves costs and increases effectiveness compared to bolting on security afterwards. To achieve this, Security Architects and Enterprise Architects need to speak the same language. That language is introduced in this Guide, which describes how to integrate security and risk into an Enterprise Architecture. It provides guidance for both security practitioners and Enterprise Architects working with the TOGAF^® standard, a standard of The Open Group [1], to develop an Enterprise Architecture.

Figure 1 summarizes this Guide. It shows how Enterprise Architecture and Enterprise Security Architecture relate to each other, highlighting the core security and risk concepts that are used in Information Security Management (ISM) and Enterprise Risk Management (ERM). These concepts are listed in the center column, and form a set of foundation concepts that complement and enhance the TOGAF Standard. Concepts with an underscore in the figure are additions to the TOGAF framework and brought in by ISM or ERM.

Figure 1: Essential Security and Risk Concepts and their Position in the TOGAF ADM

1.1 How does this Guide Support the TOGAF Standard?

This new content takes the security activities in the current TOGAF Standard [1] to a higher conceptual level. The goal of this approach is to explain how the TOGAF method and framework can be tailored to make use of an existing Enterprise Security Architecture in order to address security and risk properly.

This approach is business-driven and supports the integration of two processes: ISM and ERM. This process orientation will improve understanding of the security concepts and activities at different phases through the TOGAF Architecture Development Method (ADM). The business orientation will contribute to justification of the security components.

In this approach, it is foreseen that a lot of additional security practitioner guidance needs to be developed. This Guide provides the basis for that work. By using a common foundation this will deliver an internally consistent and practical way of working.

1.2 What about Risk Management?

Risk management in the TOGAF Standard primarily focuses on architecture project risk. This is only one type of risk. The scope of ERM, as presented in this Guide as part of the Enterprise Security Architecture, is much broader. It includes business, system, information, project, privacy, compliance, and organizational change risk, among other categories, too.

This Guide describes the broader concepts of ERM and how to integrate them into the TOGAF Standard. In particular, this work focuses on all aspects of operational risk – the risks that a business faces in day-to-day operations that are based on operational capabilities that are produced as the result of Enterprise Architecture work. It is intended that by paying more attention to operational risk downstream of the delivery of Enterprise Architecture work products, the utility, quality, and effectiveness of those work products will be improved and enhanced.

The Enterprise Security Architecture contains a balanced view on risk: negative consequences are kept to an acceptable level and positive opportunities are exploited to their maximum. The business-driven approach is key for the Security Architecture: business drivers offer the context for risk assessments; they define whether compliance with any control framework is necessary, and they justify the need for security measures.

This Guide is explicitly looking at risk within the context of best practice ERM. It is written for practitioners who expect to use best practices and are prepared to read and consider carefully the language within a profession. Like all professions, the risk management profession evolves and improves. Central to best practice ERM is a very precise definition of the term “risk”. Over the last 15 years risk management has moved the professional definition from thought leadership, to leading practice, to well established best practice. Risk definition is embedded within mainstream risk management international standards, such as ISO 31000:2009 [6], best practice guides, and derived industry-specific guides, such as the Global Association of Risk Professionals Financial Risk Manager certification.

There is a difference between the commonly accepted definition of “risk” and the risk management professional definition of the term. Within the risk management profession “risk” is defined to be the “effect that uncertainty has on the achievement of business objectives”. For many information security practitioners, this definition can feel uncomfortable: In their discipline, “risk” is usually regarded as threat-bound and therefore a negative attribute.

Since this Guide is aimed at the core concepts of the TOGAF Standard as an Enterprise Architecture framework, the definition of risk used is as defined in ISO 31000:2009. This definition allows for the usage of the term in subsequent practitioner guidance that focuses only on the narrower usage of risk as a negative; for example, in the information security risk management area, where the uncertainties are generally always negative outcomes.

1.3 Where is the Controls Checklist?

First of all, integrating security is not a matter of selecting controls from a checklist. We advocate a holistic approach towards security, so that a trustworthy, robust, reliable, secure, and risk-managed architecture is delivered. To do this, the Enterprise Security Architecture makes sure that tight cooperation is obtained between the ADM and the processes for ISM and ERM. Therefore, most of the security concepts in this Guide refer to things needed to set up security properly.

However, designing the operational security is part of the architecture as well. In the architecture context, security controls are bundled into security services. A security service can be seen as an Architecture Building Block (ABB). In the TOGAF Standard, ABBs capture architecture requirements that both direct and guide the development of Solution Building Blocks (SBBs). This can apply to all four of the TOGAF domain architectures: Business, Data, Application, and Technology. In the same way, security services capture security requirements and guide the development of sub-services and components.

Examples of security services are:

• Identity & Access Management
• Continuity Management
• Security Intelligence
• Digital Forensics
• Audit
• Network Monitoring
• Compliance Management
• Training & Awareness Programs, etc.

The security services are positioned in the logical layer of the SABSA^® architecture framework, which is developed in Phase C (Information Systems Architectures) of the TOGAF ADM. The Security Services Catalog provides the actual description of those security services.

To support security practitioners in actually designing and using the security services, a Security Services Catalog is needed. For Security Architects, the Security Services Catalog is a register that supports filling in the logical layer of the SABSA architecture framework with security controls. Unlike existing control frameworks that contain requirements, the Security Services Catalog describes security building blocks that actually deliver protection. This architecture approach enables smooth integration of information security in the Enterprise Architecture.

The standardized approach contributes to the professionalization of the security management organization and facilitates a more efficient, cost-effective way of working. One of the main advantages of the Security Services Catalog is that offers a common terminology and reference framework for the domain of security management allowing better cooperation between the parties concerned.

return to top of page