Integrating Risk and Security within a TOGAF® Enterprise Architecture

5 Security and Risk Concepts in the TOGAF ADM

The TOGAF ADM contains the concept of “artifacts” (work products) that are consumed or produced by each phase. To match this, the core concepts of the Enterprise Security Architecture are expressed in TOGAF terminology and related to TOGAF concepts, which will ensure correct embedding of the relevant risk and security concepts at the appropriate ADM phases. A complete overview of all selected SABSA artifacts is given in Figure 1.

These core security concepts are explained in more detail in the following sections for each TOGAF ADM phase. Besides the description, the location in the “Architecture Framework” is given. That can be in the TOGAF Standard – if it’s already there – or in the Enterprise Security Architecture. The Enterprise Security Architecture is used here as a generic Security Architecture concept, encompassing both ISM and ERM.

5.1 Preliminary Phase

The Preliminary Phase establishes the security context required to guide the Security Architecture design. To build the security context, the following security artifacts need to be determined during this phase. These artifacts can be integrated into existing architecture documentation.

5.1.1 Business Drivers/Business Objectives

Location in the Architecture Framework: This is the subset of TOGAF business drivers affecting security, presented as an integral part of the overall architecture business drivers (The TOGAF Standard – Architecture Content: Architecture Deliverables).

In O-ISM3 [9], this is called the business objectives. Every organization exists for specific purposes that require it to set goals and meet certain obligations. Business objectives, ranging from aspirational goals to regulatory compliance, may originate internally, or be imposed by an external party such as the government. Their achievement depends on many factors, one being information security. Some examples of business objectives are:

• Paying the payroll on the 1st of every month
• Paying all incoming invoices within a certain timeframe

5.1.2 Security Principles

Location in the Architecture Framework: Security Principles is the subset of Business Principles addressing Security Architecture. This is presented as an integral part of the overall Architecture Principles deliverable (The TOGAF Standard – Architecture Content: Architecture Deliverables).

Security Principles, like other Architecture Principles, will provide valuable guidance to making business decisions to comply with the enterprise’s risk appetite. In essence, the usage of Security Principles does not differ from the usage of Architecture Principles. Examples of Security Principles will be given in the Security Architecture Practitioners Guide.

5.1.3 Risk Appetite

Location in the Architecture Framework: Enterprise Security Architecture: ERM.

Risk appetite describes the enterprise’s attitude towards risk and provides decision-making guidance to the organization to balance the amount of risk taken to achieve an expected outcome. The risk appetite could be expressed as, for example, a boundary on a risk/business impact and likelihood grid, profit, and loss measures or qualitative measures (zero tolerance for loss of life or regulatory compliance breaches). Risk appetite can also be represented by suitably worded Security Principles, or produced as a stand-alone deliverable if a key stakeholder exists who needs to approve it specifically. It defines both the level of risk the organization is willing to accept as well as its strategy in defining this level. For risks above this acceptable level, it defines the strategy used for mitigation (transference, avoidance).

5.1.4 Key Risk Areas/Business Impact Analysis

Location in the Architecture Framework: Enterprise Security Architecture: ERM.

Note: Risk classification is described in the TOGAF Standard – ADM Techniques (Risk Management) and is focused on risk of the architecture projects. This document extends the concepts of risk and risk assessment.

During the Preliminary Phase, addressing key risk areas provides a context for architecture projects. During an architecture project in Phase A, this should be confirmed.

The business impact analysis can be applied in all domains and against the architecture roadmap, and is a powerful tool for determining fitness of the architecture and roadmap. A business impact analysis points out the potential damage (or profit) to the business that can be expected if inappropriate and insufficient information security is applied. It (only) defines what kind of impact is relevant to the business process and should be avoided, not the likelihood of this impact occurring. The deliverable is a list of the key risk areas within the architecture scope. This information is input to the risk assessment.

5.1.5 Security Resource Plan

Location in the Architecture Framework: the TOGAF Standard – Architecture Development Method, Preliminary Phase and Phase A.

Resource planning for architecture work for the entire architecture team is addressed in the Preliminary Phase when the Enterprise Architecture team is defined and established. In Phase A it is addressed where the capability of the architecture team is assessed against the architecture project.

Based on the scope of the Enterprise Architecture team’s responsibility and the scope of any architecture project, it will identify the required security resources to deliver the security elements of the architecture.

A key part of defining the Enterprise Architecture team is establishing the expected role and mandate of the Security Architect. Best practice Security Architecture integrates security and risk within all domains. Integral to this is establishing the governance process for the Security Architecture within the context of the Enterprise Architecture governance process.

Answering the following questions will assist in identifying the security and risk resources required in the team, and on an architecture project:

• What are the common security or risk-related concerns?
• Do key and influential security or risk-related stakeholders exist who require specific security views?
• Does the architecture address high-risk areas, or is the risk appetite low?
• Can security support be requested on an as-needed basis from an existing security team or are dedicated Security Architecture resources required as part of the overall architecture team?

During the Preliminary Phase it is decided which security artifacts are really needed in the Enterprise Architecture and which will be created by whom. It might not be necessary to deliver all security artifacts in order to address security properly. The reverse applies too: delivering all artifacts does not guarantee that security is taken care of properly – more artifacts may be required.

For enterprise-level architectures, the artifacts need to be created based on discussions with key stakeholders; preliminary assessments carried out by the architecture team; and assessing relevant statutes, applicable jurisdictions, legislation, and regulations.

For capability-level architectures, existing sources might be available. For instance, an enterprise-level security policy or risk assessment describes the security principles, risk appetite, and key risk areas for a particular context.

5.2 Phase A: Architecture Vision

In general, Phase A: Architecture Vision describes enough of the TOGAF ADM Phases B, C, and D to ensure that key stakeholders can agree to a vision of the end-state, which represents a solution to a defined problem.

In Phase A sufficient security-specific architecture design is carried out to:

• Satisfy the security stakeholders that the end-state does not represent any unknown or unacceptable risk and aligns with corporate policies, standards, and principles
• Satisfy business stakeholders – in particular those who control the budget – that the Security Architecture is instrumental in enabling and supporting the overall architecture required to deliver the business opportunities and benefits identified with the right balance between risk, compliance, and business benefits

In Phase A, it is essential to identify the complete list of all stakeholders, their concerns, and associated requirements for approval of the architecture. All stakeholders will have security and risk concerns and associated requirements. Separating security stakeholders ensures that the architecture will address a subset of stakeholders and a subset of requirements.

The stakeholder requirements are gathered to determine the security blueprint needed to address the various concerns the stakeholders have. The security blueprint is defined at a level giving sufficient assurance to the stakeholders that the final artifacts and deliverables will address their concerns appropriately. The ADM phases related with architecture descriptions complete the blueprint and add the required detail.

Stakeholders typically have value concerns related to the Security Architecture. Value may be measuring items such as reduced risk and enablement of the overall architecture. The Business Attribute Profile[1] can be useful as a basis for the business case. As a specific Business Attribute Profile may not yet be available, the SABSA-provided Business Attribute Profile can be used as a starting point. A scenario-based approach may be used to obtain stakeholder approval.

The viewpoints and business cases must build on Security Principles, drivers, key risks, and risk appetite and should be an integral part of the overall Architecture Vision deliverables.

5.3 Phase B: Business Architecture

The security elements of Phase B: Business Architecture comprise business-level trust, risk, and controls, independent from specific IT or other systems within the specific scope of the architecture engagement.

The security-related Business Architecture artifacts are described below.

5.3.1 Security Policy Architecture

Location in the Architecture Framework: Enterprise Security Architecture: ISM.

The Security Policy Architecture (or Framework) contains a set of security policies that express the security strategy. It assigns ownership and accountability for security and risk management. It also addresses the linkage and hierarchy of operational risk management in general with the various security aspects such as business continuity, information security, system security, and physical security.

5.3.2 Security Domain Model

Location in the Architecture Framework: the TOGAF Standard – Introduction and Core Concepts (Glossary of Supplementary Definitions: Information Domain). Complete text: “Grouping of information (or data entities) by a set of criteria such as security classification, ownership, location, etc. In the context of security, information domains are defined as a set of users, their information objects, and a security policy.”

Note: The concept of information domain corresponds with the definition of a security domain below.

A security domain represents a set of assets that could be described by a similar set of business attributes. In other words, the security domain groups the assets with the same security level that fall under the jurisdiction of one security policy. In addition, the security domain model helps in defining responsibility areas where responsibility is exchanged with external parties. It can also be used to distinguish between areas of different security or trust levels. A security policy authority is responsible for setting and implementing the security policy within the domain.

If the business model of the organization does encompass federation with other organizations, the extent of the security federation should be established at this point in the process. This is the case when organizations have data objects or activities in common. Contractual federation agreements should be examined for their security implications and agreements. It may be necessary to establish joint architecture meetings with other members of a federation if they belong to the same security domain.

5.3.3 Trust Framework

Location in the Architecture Framework: Enterprise Security Architecture: ISM.

Trust relationships are the basis for doing business with other parties. The trust framework describes trust relationships between various entities in the architecture domain and on what basis this trust exists. Trust relationships can be unidirectional, bidirectional, or non-existent. The onus for assessing trust is the responsibility of those choosing to enter into the contracts and their legal counsel. It is important to note that technology (e.g., digital certificates) cannot create trust, but can only convey in the electronic world the trust that already exists in the real world through business relationships, legal agreements, and security policy consistencies.[2]

5.3.4 Risk Assessment

Location in the Architecture Framework: Enterprise Security Architecture: ERM.

Although the TOGAF Standard – ADM Techniques (Initial Risk Assessment) describes one method of administrating the result of a risk assessment, the actual act of assessing risk and the ways to do that are not described. Therefore, this concept is augmented by this document for use with the TOGAF Standard.

A risk assessment is the activity of determining the risks that are relevant to an asset or objective. A qualitative risk assessment delivers a listing of relevant risk scenarios with a high-level prioritization (high-medium-low), whereas a quantitative approach seeks for numeric determination of the risk. This is commonly based on identified threats, their likelihood of materializing, and the impact of an incident. A deliverable of a risk assessment is the Business Risk Model.

5.3.5 Business Risk Model/Risk Register

Location in the Architecture Framework: Enterprise Security Architecture: ERM.

The Business Risk Model is a Risk Register. It determines the cost (both qualitative and quantitative) of asset loss/impact in failure cases. It is the result of a risk assessment, based on identified threats, likelihood of materializing, and impact of an incident. Business impact should be aligned with the definitions in the Business Attribute Profile, which act as pseudo-assets. Security classification should be carried out at this stage based on the risks identified. The business risk model is a detailing of the risk strategy of an organization. The classification of the information determines the maximum risk the business is willing to accept, and the owner of the information decides what mitigation is enough for his/her information.

5.3.6 Applicable Law and Regulation Register

Location in the Architecture Framework: Enterprise Security Architecture: ISM.

The Applicable Law and Regulation Register contains the specific laws and regulations that apply within the scope of the Enterprise Architecture engagement, based on the business function inventory. It is kept up-to-date, following legal and regulatory changes. This register is important for compliance purposes.

Whether the business function is subject to regulation depends upon the functionality of the system as a whole and the data collected or maintained. In addition, the jurisdiction where the supporting systems or services are deployed, where the users reside, etc. is relevant information. It may be wise to obtain legal counsel regarding these obligations at the outset of activities.

5.3.7 Applicable Control Framework Register

Location in the Architecture Framework: Enterprise Security Architecture: ISM.

The Applicable Control Framework Register contains the suitable set of control frameworks that best satisfy the requirements and address the risks related to the engagement scope and context. Control frameworks contain requirements and/or mandatory security measures. Examples of control frameworks are ISO/IEC 27001:2013 [4], ISO/IEC 27002:2013 [5], COBIT [10], PCI-DSS, Common Criteria, etc.

Factors that drive the selection of control frameworks are:

• Mandatory certifications, due to the nature of the business process or the industry
• Way of working of the internal ISM process – this is often inspired by ISO/IEC 27001:2013 but might mandate additional control frameworks as well
• Marketing objectives – customers may ask for specific control framework certifications
• Support for security audits

5.4 Phase C: Information Systems Architectures

The security elements of Phase C: Information Systems Architectures comprise functional security services and their security classification.

The artifacts are described in more detail below.

5.4.1 Security Services Catalog

Location in the Architecture Framework: Enterprise Security Architecture: ISM.

Note: The TOGAF Standard has a Business Services Catalog that is a list of the enterprise's business services and their functional and non-functional requirements. It is used to analyze the functional and non-functional requirements. The Security Services Catalog stores and provides more kinds of information about each service, so this needs to be introduced.

The Security Services Catalog is a list of services that provide security-specific functionality as part of the overall architecture. Unlike control frameworks that contain requirements, the Security Services Catalog describes security building blocks that actually realize the security goals. It provides a common terminology and reference framework for the domain of security management. The Security Services Catalog contains conceptual definitions of the services, as well as operational information about implementation and usage.

Examples of security services are:

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

This is the area of security that most security practitioners will recognize. One of the main advantages of the Security Services Catalog is that it is a common terminology and reference framework for the domain of security management allowing better cooperation between the parties concerned.

5.4.2 Security Classification

Location in the Architecture Framework: Enterprise Security Architecture: ISM.

Security classification is a label attached to an asset, according to a classification scheme. In most cases, this scheme is defined and described in the corporate information security policy and the classification is based on one or more characteristics of the asset.

Keep in mind that the asset can be any relevant component of the architecture. Assets include business service, a capability, information, an information system service, physical data component, or physical technology component. The security classification determines the security requirements that apply to the asset; for example, regarding access control, confidentiality, or availability. It is a means to implement the security policy.

5.4.3 Data Quality

Note: From an Enterprise Security Architecture perspective, data quality[3] requirements are an integral part of the security requirements and so are the related risk assessment and selection of measures.

Data quality is a key factor in operational risk management. Some of the key attributes that contribute to data quality are accuracy, relevance, timeliness, currency, completeness, consistency, availability, and accessibility. Safeguarding data quality starts with a clear overview on the datasets in question. For each dataset, ownership and responsibility for the quality of data needs to be assigned. The owner authorizes people or processes that are trusted for a certain activity on the data under certain circumstances. It might also be necessary to change information systems in order to handle the data properly. Finally, each of the key attributes should be measured based on log and performance data.

5.5 Phase D: Technology Architecture

In most cases, the development of specific Technology Architecture security artifacts is not necessary, as long as it incorporates the relevant security controls and mechanisms defined in earlier phases. The Security Architect must ensure that the required controls are included in the Technology Architecture and verify whether the controls are used in an effective and efficient way. This includes the technology for the provision and regulation of system resources, such as electric power, processing capacity, network bandwidth, and memory.

A security stakeholder may request the creation of a specific Technology Architecture security view or deliverable that describes all security-related technology components and how they inter-relate. This view should explain which business risks are mitigated by what technology, providing justification for the technology.

5.6 Phase E: Opportunities and Solutions

In defining the roadmap, where the sequence of gaps to be addressed is determined, it is imperative that security and risk are evaluated. Ensure the stakeholders’ security and risk concerns are addressed in the analysis. Confirm that risk owners are consulted. The value expected to be delivered by work packages should include measures related to security and risk value to ensure the roadmap addresses the complete set of business goals and drivers.

The security building blocks defined in the previous phases become SBBs in this phase so that more specific implementation-oriented requirements and specifications are defined. A whole solution design might be needed at this stage.

The Security Services Catalog of the Baseline Security Architecture probably contains existing security services or security building blocks that meet the requirements. For example, if the requirement exists for application access control, an existing central authentication service might be used to fill that in. The efficacy of existing security services and controls earmarked for re-use must be verified to ensure that the end-state contains security measures, which work and integrate well.

5.6.1 Risk Mitigation Plan

Location in the Architecture Framework: Enterprise Security Architecture: ERM.

Note: In the TOGAF Standard, 10^th Edition risk mitigation is done for transition risks, but it is not explained how this should be created or what possible risk mitigation strategies there are, so this document provides additional guidance on this issue.

The Risk Mitigation Plan contains activities to mitigate risks. It is the implementation of the risk mitigation strategy, which could aim to increase the level of control, transfer the risk to another party, avoid the risk by changing the business activity, delay the risk, compensate for the risk, etc.

The broader sense of risk is addressed by the ERM process in this phase. The scope includes the latest information security risks as identified during the risk assessments that are done earlier in the ADM (in Phase B). This is where the risks get “solutioned” or “treated”. The Risk Mitigation Plan should also consider risks that appear as a result of the new architecture.

5.7 Phase F: Migration Planning

Migration is itself a business process that needs to be secured. The migration strategy should include a risk assessment and a Risk Mitigation Plan. In Phase F, the Risk Mitigation Plan is limited to the transition. These concepts have already been mentioned in earlier phases of the ADM. Migration of live environments should always include regression planning so that there is a way to reverse out a failed migration. This is an essential part of risk management.

In addition, migration planning should include a security impact analysis to understand any security impacts of the target state of the change.

5.8 Phase G: Implementation Governance

Security Architecture implementation governance provides assurance that the detailed design and implemented processes and systems adhere to the overall Security Architecture. This ensures that deviations from Architecture Principles and implementation guidelines don’t create any unacceptable risk.

The following artifacts are relevant in this phase.

5.8.1 Security Audit

Location in the Architecture Framework: Enterprise Security Architecture: ISM.

Security audit includes security reviews of implemented processes, technical designs, developed code, and configurations against policies and requirements. It also includes security testing, comprising functional security testing, performance testing, and penetration testing.

5.8.2 Security Training and Awareness

Location in the Architecture Framework: Enterprise Security Architecture: ISM.

Security training and awareness means that sufficient training is provided to ensure correct deployment, configuration, and operations of security-relevant subsystems and components; including awareness training of all users and non-privileged operators of the system and/or its components. It is critical for a proper, continuous, and secure performance.

In many control frameworks, security training must be followed and results documented to demonstrate due diligence. Substantiated corrective actions or sanctions are needed in cases where exploits or errors compromise security objectives.

5.9 Phase H: Architecture Change Management

Phase H does not produce tangible security outputs but defines two processes essential for continued alignment between the business requirements and the architecture: risk management and architecture governance. Even though they are not formal artifacts, they are added here to emphasize their importance.

ERM is the process in which the existing architecture is continuously evaluated regarding changes to business opportunity and security threat. Based on the results of this process, the current architecture might deem it unsuitable to mitigate changed or new risks, or it might constrain the business too much in exploiting new opportunities. In that case, a decision on architecture change must be made.

Architecture governance is the process in which decisions are made on changes to the existing architecture, either by minor changes in the current iteration or by means of a completely new iteration. This is explained in the TOGAF Standard – Enterprise Architecture Capability and Governance (Architecture Governance Framework). Changes related to risk and security should be an explicit part of that framework. Large changes to the architecture should include a security impact analysis.

Change is driven by new requirements or changes in the environment. For instance, changes in security requirements can be caused by changes in the threat environment, changed compliance requirements, or changes due to discovered vulnerabilities in the existing processes and solutions. Changes required due to security-related causes are often more disruptive than a simplification or incremental change.

Due care must be taken in deciding whether a security change triggers a new iteration though the TOGAF ADM cycle – for instance, when enterprise risk appetite changes – a seemingly small security requirement change can easily trigger a new architecture development cycle.

An example of where changes can be applied within the existing architecture is when security standards or requirements change. This is usually less disruptive since the trade-off for their adoption is based on the value of the change – that is, evaluation of the risk – the trade-off between the opportunity for business improvement, the perceived threat to the business in security terms, and the threat posed by the change itself, which would perhaps be very disruptive and expensive. This is an excellent example of where the SABSA concept of balancing risks can be applied to decision-making.

It is therefore essential that the architecture change board or any other governance structure that is responsible for applying appropriate architecture change management comprises suitable security skilled individuals.

5.10      Requirements Management

Requirements Management plays a central role in architecture work. This is recognized in the TOGAF Standard. The purpose of Requirements Management is to identify, store, maintain, and communicate business requirements through the different phases of architecture development by means of a controlled and repeatable process. In addition, operational performance is monitored against target requirements. This is not explicitly addressed in the TOGAF ADM but lies within Phase H: Architecture Change Management, and the continual validation of Requirements Management.

The TOGAF method validates and updates business requirements in every stage of an architecture development project. However, the TOGAF Standard does not provide a required technique for describing or documenting requirements. Such a technique is present in SABSA, which presents its unique Business Attribute Profiling technique as a means to describe requirements effectively. This section describes the use of Business Attribute Profiling with respect to security requirements management, along with the benefit this technique offers for Requirements Management in general.

5.10.1 Business Attribute Profile

Location in the Architecture Framework: Enterprise Security Architecture: ISM.

Business Attribute Profiling is a SABSA requirements engineering technique that translates business goals and drivers into requirements using a risk-based approach. Some important advantages of this technique are:

• Executive communication in non-IT terms
• Traceability mapping between business drivers and requirements
• Performance measurement against business-defined targets
• Grouping and structuring of requirements, which facilitates understanding and oversight by architects

The SABSA Business Attribute Profile is at the heart of the SABSA methodology. It is this requirements engineering technique that makes SABSA truly unique and provides the linkage between business requirements and technology/process design. See the SABSA^® Blue Book [2].

© The SABSA Institute

Figure 6: Example of a SABSA Business Attribute Taxonomy

Each SABSA Business Attribute in the example taxonomy of Figure 6 has a detailed generic definition and some suggested guidelines for applying metrics to that attribute, not included in this overview. A Business Attribute Profile is built by the architects, using the taxonomy as a guideline. The objective is to document the relevant attributes for the business case in hand, redefining each selected attribute in terms of the business case, developing a measurement approach, specific metrics, and performance targets, again related to the business case. The model is flexible and adaptive. When needed, new attributes and new definitions should be added to fulfill the business requirements. Thus, although the method is well defined, the Business Attribute taxonomy can be extended as much as is appropriate and each Business Attribute Profile is highly customized according to the business case being considered by the architecture team.

An integral part of the SABSA Business Attribute Profile is the selection of metrics to set targets, so that performance can be measured in the operational phase (“did you hit the target?”). The business analyst can choose to either use the suggested metrics in the detailed examples, or create new metrics if that seems more appropriate. Eventually, the creation of a real-time operational risk dashboard is possible that monitors performance of operational capabilities against the predetermined performance targets, and provides early warnings of up-coming risk events that may require management intervention.

In O-ISM3, performance targets are called “security targets”. As well as expressing security objectives in terms of what matters to the business, O-ISM3 defines the tolerable deviations. All O-ISM3 objectives (business and security) must include their security target. This is the maximum deviation from the desired outcome that management tolerates before taking corrective action. O-ISM3 can support any specified variance. This enables the O-ISM3 program to support and manage both aspirational objectives (whose allowable deviations may be very high) and critical objectives (where there is usually a very narrow compliance range).

Security targets are normally defined in terms of frequency of occurrence and threshold cost. The allowable business impact of missing objectives reflects the trade-off against other priorities and objectives. Security targets show what the organization expects from its information security investment. In a way, management’s act of defining security targets also specifies its risk appetite.

5.10.2 Control Objectives/Security Objectives

Location in the Architecture Framework: Enterprise Security Architecture: ISM.

A control objective (sometimes called a security objective) is a desired state of security for a given process, person, activity, system, or dataset. It differs from a security requirement since an objective is a goal that the ISM process aims to fulfill. This control objective might not exactly match the security requirement. Control objectives are linked to business attributes.

O-ISM3 documents the contribution of information security towards meeting business objectives through using a dependency analysis. The output of the dependency analysis is a list of security objectives that form the basis for design, implementation, and monitoring of the ISMS. They also form the business objectives for the security component when planning Enterprise Architecture. Security objectives, derived from business objectives, state explicitly how information security contributes to business objectives.

Some examples of security objectives derived from the business objective “Invoicing all products and services provided” are:

• Invoices are accessible only to the accountancy and collection teams
• Paid invoices are kept for three years and destroyed after no more than four years

5.10.3 Security Standards

Location in the Architecture Framework: the TOGAF Standard – Architecture Content (Standards Library) provides a repository area to hold a set of specifications to which architectures must conform. The standards can apply at every architecture domain in the TOGAF Standard. Security standards can be added to this existing catalog as well.

The Security Architecture provides guidance on which security standards to use in which situation. Whether a security standard applies is decided by the business owner or business analyst. If so, the standard is applied to the architecture work through the Requirements Management process. The standard can dictate security controls for the Business, Data, Application, or Technology Architecture.

Standards are needed to ensure that many different components can be integrated to form a larger system. Different types of standards exist, such as regulatory standards, technical standards, etc. An example is the PCI-DSS standard that applies for businesses in the payment card industry, the ETSI standards that apply in the telecom industry, etc. It is also worth noting that security standards may be externally imposed, or they may be internally developed.

5.11      The TOGAF Architecture Content Metamodel

The TOGAF Architecture Content Metamodel includes the necessary concepts to model ISM and ERM. Existing entities, such as business service and information system service, are adapted by having ISM and ERM-specific attributes.

5.12      Use of the ArchiMate^® Modeling Language

The ArchiMate language [8] supports ISM and ERM modeling. This is described in The Open Group White Paper: Modeling Enterprise Risk Management and Security with the ArchiMate^® Language [12]. An example of the risk model in the ArchiMate language is given in Figure 7.

Figure 7: Modeling Risk and Security in the ArchiMate Language

---

Footnotes

return to top of page

---

---