3 Enterprise Security 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. It is an enabler/driver of secure behavior, safe behavior, resilient behavior, reliable behavior, and upholding of privacy at risk areas throughout the whole enterprise.

Security Architecture components always have a relationship with other elements in the architecture. Thus, although the Security Architecture might be viewed as one architecture, it can never be an isolated architecture.

The risks managed by the Security Architecture are of various kinds. Two important ones are business risk and operational risk. The 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.

For true integration of security in the architecture, a system engineering approach should be used. This means that security and risk are considered as soon as possible in the system engineering development lifecycle of the subject in question. At each phase in the development lifecycle, appropriate security and risk-related activities are conducted. These activities might vary from high-level advice and guidance in the early phases up to detailed security checks in the final phase. In this way, a secure operational system can be achieved that is reliable, safe, resilient, and respectful of privacy concerns. In addition, it leads to secure behavior.

In the operational phase, the security aspects of the architectures should be monitored, assessed, and reported. Although this operational phase generally does not begin until the first iteration of the TOGAF ADM is complete, it is during the ADM Phases G and H that the capabilities to measure security need to be designed and incorporated.

The adjective “Enterprise” before “Security Architecture” indicates the abstraction layer that the Security Architecture addresses. The concept of “enterprise” implies business alignment at the highest level, rather than at local levels. The TOGAF Standard defines “enterprise” as the highest level of description of an organization and typically covers all missions and functions. It further states than an enterprise will often span multiple organizations. For example, an enterprise could be a government agency, a whole corporation, a division of a corporation, a single department, or a chain of geographically distant organizations linked together by common ownership.

The Enterprise Security Architecture seeks business alignment of the security measures with the business objectives. It does so by defining relationships between the components on the different architecture layers, thus providing traceability and justification. The Enterprise Security Architect typically makes use of ISM and ERM processes to develop the deliverables and to interact with stakeholders.

3.1 Enterprise Risk Management

The Information Technology security and information security industry has evolved over its lifetime a view of operational risk that is concerned only with threats, vulnerabilities, and loss events (negative impacts). However, as noted earlier in Section 1.2, this Guide uses the ISO 31000:2009 [6] definition of “risk”, an “uncertainty of outcomes”, and risk management is presented as striking a balance between positive and negative outcomes resulting from the realization of either opportunities or threats.

3.1.1 Definition of Risk

Risk is the “effect of uncertainty on objectives” (ISO 31000:2009 [6]).

The effect of uncertainty is any deviation from what is expected – positive and negative.

Understanding the term “risk” is central to understanding the broader concepts of ERM, and the role of effective Enterprise Architecture and Enterprise Security Architecture. In this Guide we define risk in line with ISO 31000:2009. Risk is the effect that uncertainty has on the achievement of business objectives. The uncertainty is concerned with predicting future outcomes, given the limited amount of information available when making a business decision. This information can never be perfect, although our expectation is that given better quality information we can make better quality decisions. Every decision is based on assessing the balance between potential opportunities and threats, the likelihood of beneficial outcomes versus damaging outcomes, the magnitude of these potential positive or negative events, and the likelihood associated with each identified outcome. Identifying and assessing these factors is known as “risk assessment” or “risk analysis”. “Risk management” is the art and science of applying these concepts in the decision-making process. Risk can be seen at the strategic long-term level (overall direction of the business), the medium term tactical level (transformation projects and programs), and at the operational level (regular day-to-day operational decisions, processes, and practices). The objective of risk management is to optimize business outcomes to maximize business value and minimize business losses. Risk can be seen at any level in the business stack (see Figure 2), but is always driven top-down from assessment of business value and its optimization.

© The SABSA Institute

Figure 2: Business Risk versus Cyber Risk Areas

Uncertainty typically involves a deficiency of information and leads to inadequate or incomplete knowledge or understanding. In the context of risk management, uncertainty exists whenever the knowledge or understanding of an event, consequence, or likelihood is inadequate or incomplete.

This balanced view of risk is also embedded in SABSA, including the enabling of benefits arising from opportunities as well as the control of the effects of threats. Arguably, the sole role of the Enterprise Architect is to create an operational environment in which operational risk can be optimized for maximum business benefit and minimum business loss.

© The SABSA Institute

Figure 3: The SABSA Operational Risk Model

Operational risk is concerned with the threats and opportunities arising in business operations. SABSA is an architectural and operational framework for reaching out to opportunities and enabling positive outcomes to attain defined business targets and managing negative outcomes of loss events to within an enterprise’s tolerance towards risk – namely their risk appetite.

3.1.2 Core Concepts for Enterprise Risk Management

According to ISO 31000:2009, the risk management process aids decision-making by taking account of uncertainty and the possibility of future events or circumstances (intended or unintended) and their effects on agreed objectives. It also gives a risk management process model, as illustrated in Figure 4. The ISO 31000:2009 approach makes it clear that risk management should be embedded deeply and firmly in all business activities. It also states that it is a continuous lifecycle rather than an isolated activity. This definition of risk management is adopted in this work.

The heart of this definition is that effective risk management is about managing to the expected objective. Every step has an element of risk that needs to be managed and every outcome is uncertain. ERM is about reducing uncertainty.

Figure 4: ISO 31000:2009 Model for Risk Management (Derived from[6])

The following concepts are important for ERM:

3.2 Information Security Management

Information Security Management (ISM) is a process that defines the security objectives, assigns ownership of information security risks, and supports the implementation of security measures. The security management process includes risk assessment, the definition and proper implementation of security measures, reporting about security status (measures defined, in place, and working), and the handling of security incidents.

3.2.1 Security

For many security practitioners, security is based on three core pillars: Confidentiality, Integrity, and Availability – also known as the CIA triad. These work pretty well in a technical environment where information systems need to be classified in order to determine the security requirements that apply. Classification can be achieved according to the confidentiality scheme (high-medium-low). Especially in the financial industry, these schemes for security classification based on the CIA triad are pervasive through the whole organization.

However, when talking with business owners it often turns out that these terms are meaningless to them. They have a clear understanding of which people are allowed to access which systems, but they don’t use these “security” terms for that. In addition, the three terms are too broad. It’s possible to rank every security concern under one of those three terms. The fact that they are so broadly defined is also their weakness: they can mean something completely different in two different environments.

For example, “Availability” can stand for:

This example illustrates that Availability can have all kinds of meanings, depending on scope and context. It also illustrates that terms that are more specific are at our disposal that specify the type of concern we need to address. If the terms are so complex and need to be analyzed each time to determine what we really mean, then why should we keep using those terms? The terms Confidentiality, Integrity, and Availability are overloaded, used by many people for different purposes. We need a more specific concept.

Therefore, in this work we move away from the narrow CIA triad to a very rich terminology that is both specific and business-friendly. This is offered by the SABSA Business Attribute model, as described in the section “Requirements Management”. Business Attributes offer a flexible and powerful way of expressing the security concerns of the business owners.

The Business Attribute model also allows for measurement of efficacy. The efficacy of a security measure is considered in relation to the risk it mitigates. An enterprise cannot determine how much it will be willing to spend on securing an asset until it understands the asset value. For example, the use of that asset in an application and the concomitant risk the asset is exposed to as a result, will determine the true requirements for security. Additionally, the organization’s tolerance for risk is a factor. In other words, the question asked should not be: “Is it secure?”, but rather: “Is it secure enough?”. The latter is ultimately a question to be answered by risk evaluation.

To give a more down-to-earth idea of what security encompasses, some generally accepted areas of concern for the Security Architect are given:

3.2.2 Privacy

Privacy is the ability of an individual or group to seclude themselves, or information about themselves. The boundaries and content of what is considered private differ among cultures and individuals, but share common themes. The domain of privacy partially overlaps security, including, for instance, the concepts of appropriate use, as well as protection of information.

In general, directives on privacy demand that personal data should not be processed at all, except when certain conditions are met. These conditions fall into three categories: transparency, legitimate purpose, and proportionality.

3.2.3 Core Concepts for Information Security Management

According to ISO/IEC 27001:2013 [4], the ISM system preserves the security aspects of information by applying a risk management process, and it gives confidence to interested parties that risks are adequately managed. The ISM system is part of and is integrated with the organization’s processes and overall management structure. The standard specifies the requirements for the ISM system.

The following core security concepts are relevant for the ISM process. Their descriptions as well as their relationship with the TOGAF ADM are given later in this Guide. Their role in the ISM process will be described in the Security Architecture Practitioners Guide. They are listed here in order to enumerate the core information security concepts that should be part of the TOGAF Standard. The main categories of ISO/IEC 27001:2013 are used to understand better how the concepts are related.

Context of the Organization

Leadership

Planning

Support

Operation

Performance Evaluation

Improvement

3.2.4 Operational Security Processes

Operational controls are designed during TOGAF ADM Phases B, C, D, and E. ADM Phases F and G provide guidance on the definition of metrics that would be used later during the project operations. This is why the operational security processes are introduced in the design phase as part of the Security Services Catalog.

The consequence is that operational security processes, such as digital forensics, security intelligence, and security analytics, will be found in the architectures as part of the Security Services Catalog. Security intelligence provides the means to analyze and measure enormous amounts of data and deliver meaningful incident information to the right people across the organization.

return to top of page

Copyright © 2022 The Open Group, All Rights Reserved.
TOGAF® is a registered trademark of The Open Group
<<< Previous Home Next >>>