Search Results for: open group

Until quite recently, IT security was the exclusive domain of security specialists. However, in the last couple of years, organizations have started to realize that IT-related risks cannot be seen in isolation, and should be considered as an integral part of Enterprise Risk and Security Management (ERSM). ERSM includes methods and techniques used by organizations to manage all types of risks related to the achievements of their objectives.

It is only natural to place ERSM in the context of Enterprise Architecture (EA), which provides a holistic view on the structure and design of the organization. Therefore, it is not surprising that EA methods such as TOGAF include chapters on risk and security (although the integration of these topics in the overall approach is still open for improvement), and a security framework such as SABSA shows a remarkable similarity to the Zachman framework for EA. And as a corollary, it also makes perfect sense to use the ArchiMate language to model risk and security aspects.

The previous blog post in this series outlined a method for EA-based ERSM with ArchiMate. This article proposes an initial mapping of risk and security concepts to ArchiMate concepts, and illustrates how these concepts can be used as a basis for performing an organization-wide risk assessment.

ArchiMate mapping of risk concepts

Most of the concepts used in ERSM standards and frameworks can easily be mapped to existing ArchiMate concepts. And since ERSM is concerned with risks related to the achievement of business objectives, these are primarily concepts from the motivation extension. 

• Any core element represented in the architecture can be an asset, i.e., something of value susceptible to loss that the organization wants to protect. These assets may have vulnerabilities, which may make them the target of attack or accidental loss.

• A threat may result in threat events, targeting the vulnerabilities of assets, and may have an associated threat agent, i.e., an actor or component that (intentionally or unintentionally) causes the threat. Depending on the threat capability and vulnerability, the occurrence of a threat event may or may not lead to a loss event.

• Risk is a (qualitative or quantitative) assessment of probable loss, in terms of the loss event frequency and the probable loss magnitude (informally, ‘likelihood times impact’).

• Based on the outcome of a risk assessment, we may decide to either accept the risk, or set control objectives (i.e., high-level security requirements) to mitigate the risk, leading to requirements for control measures. The selection of control measures may be guided by predefined security principles. These control measures are realized by any set of core elements, such as business process (e.g., a risk management process), application services (e.g., an authentication service) or nodes (e.g., a firewall).

ArchiMate mapping of risk concepts

Using one of the extension mechanisms as described in the ArchiMate standard, risk-related attributes can be assigned to these concepts. The Factor Analysis of Information Risk (FAIR) taxonomy, adopted by The Open Group, provides a good starting point for this.

Qualitative risk assessment

If sufficiently accurate estimates of the input values are available, quantitative risk analysis provides the most reliable basis for risk-based decision making. However, in practice, these estimates are often difficult to obtain. Therefore, FAIR proposes a risk assessment based on qualitative (ordinal) measures, e.g., threat capability ranging from ‘very low’ to ‘very high’, and risk ranging from ‘low’ to ‘critical’. The following picture shows how these values can be linked to elements in an ArchiMate model, and how they can be visualized in ‘heat maps’:

• The level of vulnerability (Vuln) depends on the threat capability (TCap) and the control strength (CS). Applying control measures with a high control strength reduces the vulnerability level.

• The loss event frequency (LEF) depends on both the threat event frequency (TEF) and the level of vulnerability. A higher vulnerability increases the probability that a threat event will trigger a loss event.

• The level of risk is determined by the loss event frequency and the probable loss magnitude (PLM). 

Qualitative risk assessment

The example below shows a simple application of such an assessment. A vulnerability scan of the payment system of an insurance company has shown that the encryption level of transmitted payment data is low (e.g., due to an outdated version of the used encryption protocol). This enables a man-in-the-middle attack, in which an attacker may modify the data to make unauthorized payments, e.g., by changing the receiving bank account. For a hacker with medium skills (medium threat capability) and no additional control measures, this leads to a very high vulnerability (according to the vulnerability matrix above). Assuming a low threat event frequency (e.g., on average one attempted attack per month), according to the loss event frequency matrix, the expected loss event frequency is also low. Finally, assuming a high probable loss magnitude, the resulting level of risk is high. As a preventive measure, a stronger encryption protocol may be applied. By modifying the parameters, it can be shown that increasing the control strength to ‘high’ or ‘very high’, the residual risk can be reduced to medium. Further reduction of this risk would require other measures, e.g., measures to limit the probable loss magnitude.

Risk analysis example

By linking risk-related properties to ArchiMate concepts, risk analysis can be automated with the help of a modeling tool. In this way, it becomes easy to analyze the impact of changes in these values throughout the organization, as well as the effect of potential control measures to mitigate the risks. For example, the business impact of risks caused by vulnerabilities in IT systems or infrastructure can be visualized in a way that optimally supports security decisions made by managers.

In a recent article on Forbes.com with the provocative title “Is Enterprise Architecture Completely Broken?”, Jason Bloomberg gives a scathing critique of the state of practice in EA. His main point is that many enterprise architects overly focus on documentation and frameworks, instead of delivering real value and effecting business change. In short: architecture slows things down, rather than providing business value and agility. Although the article exaggerates the problem, it does touch on an important challenge for enterprise architects.

Some enterprise architecture practices are indeed concerned first and foremost with documenting the current state of the enterprise in detail. Often this is the result of the risk-averse and bureaucratic culture we encounter in many large, IT-intensive organizations. This kind of bookkeeping will never be complete, given the increasing pace of change organizations have to deal with. Of course, there is value in having a sufficiently accurate view of the business processes, applications and infrastructure of an organization. Herein lies the real challenge: we need just enough insight (a) to keep these complicated environments running and (b) to aid the enterprise architect, who should concentrate on the future direction of the enterprise.

Key to a successful EA practice is to focus on change. On the one hand, this requires process agility: rapid development and realization processes consisting of feedback loops to design, implement and measure enterprise-wide change. Classical, feed- forward, waterfall-like approaches simply won’t work in today’s volatile business environment. Using agile practices in EA processes is an important way to foster this   focus on change. On the other hand, EA products need to realize system agility: having organizational and technical systems that are easy to reconfigure, adapt and extend   when the need arises. Together, agile processes and systems create a foundation for true business agility: using your ability to change as an essential part of your enterprise strategy, outmaneuvering competitors with shorter time-to-market, smarter partnering strategies, lower development costs and higher customer satisfaction.

This focus on change is not just an EA issue, but involves all disciplines contributing to  business transformation. This point is missed by Bloomberg’s article, which focuses on  EA as a stand-alone discipline. However, successful enterprises manage their business   transformations from an integral perspective in which EA is a key player, strongly interlinked with other fields. The difficulties many organizations have with strategy execution show that this is not a sinecure.

As I have described in previous blog posts (1, 2, 3), a number of important connections between EA and other disciplines help in putting the architecture to work in effecting  business change with a holistic perspective:

• Strategy development: Of course, it all starts with strategic direction. Many organizations have great strategies, but lack the ability to execute them. A sound EA practice bridges the gap between abstract, high-level strategies and concrete operational decisions, and provides feedback on the feasibility and impact of strategic choices.

• Capability-based planning: Business capabilities are a pivot between strategy and realization. They provide a high-level view of the current and desired abilities of an organization, in relation to the organization’s strategy and its environment, and they are a starting point for more concrete developments in the enterprise.

• Enterprise portfolio management: Managing investments in your capabilities is essential in effecting business change. Enterprise portfolio management provides the instruments to select areas for investment and change initiatives to realize the enterprise strategy. Enterprise architecture provides the necessary information about current and required capabilities and their dependencies to support a coherent portfolio management practice.

• Program management: Managing change initiatives from the perspective of business outcomes is the core task of program management. The overview provided by EA is key in managing change in an integral manner, taking account of various dependencies and interactions within the enterprise and across its boundaries.

• Risk management: Better alignment between enterprise strategy, architecture and implementation helps the organization to spend its risk and security budget wisely, focused on business-relevant risks. This may lead to both cost savings and lower risks at the same time, because you invest to protect the things your enterprise really cares about.

• Regulatory compliance: Implementing standards and policies such as SEPA, Solvency II, Basel III and others requires enterprise-wide coordination, visibility and traceability from boardroom-level decisions on e.g. risk appetite of the organization, down to the implementation of measures and controls in business processes and IT systems. Enterprise architecture is indispensable to manage the wide-ranging impact of such developments.

• Continuous delivery and improvement: Modern approaches to realization manage  the assets that make up your enterprise across their entire life cycle, doing away with the artificial distinction between ‘development’ and ‘maintenance’. Continuous improvement of business processes by Lean management and continuous delivery of software by agile & DevOps teams provides a steady stream of business value, in close interaction with customers and other stakeholders. Enterprise architecture connects these value streams, to ensure a coherent approach to change and to avoid building ‘agile silos’.

​In all of these areas, EA functions as a kind of ‘enterprise knowledge hub’, integrating  and sharing information on various structures across the enterprise and the business transformation value chain. It provides you with relevant input for prioritizing and planning transformations. It gives you program-level coordination across value streams to realize these changes in a coherent manner. It helps you to track the realization of the expected benefits, and hence to correct your course if necessary.

Enterprise architecture as knowledge hub.

 

At BiZZdesign, we help our clients in establishing such a change capability, where we  pragmatically employ practices from various methods and techniques. Each activity and deliverable in your change processes should add business value, and we take a ‘lean and mean’ approach to the use of established methods such as TOGAF.

No one in his right mind would implement something like TOGAF cover-to-cover (which isn’t TOGAF’s intention anyway, but this is not always understood). This would indeed  lead to the document- and framework-centric EA practice that Bloomberg condemns, but to me this is largely a straw man argument. Instead, smart organizations use such methods as a source of inspiration and pick and choose those elements that fit within their specific context. Professional communities like those of The Open Group or the OMG are invaluable in bringing together practitioners and collecting best practices. At BiZZdesign, we also share such practices with our clients and others, by writing books, whitepapers and blogs like these, and by actively contributing to the activities of these communities.