IT Risk Management Based on COBIT 5 for Risk at Deutsche Telekom AG

The purpose of risk management is to protect the values of an organization.¹ This means that risk management first describes methods and procedures for analyzing potential scenarios that, if they occur, could have a negative effect on the organization. Organizations that are reliant on functioning IT operations are, therefore, faced with the challenge of identifying the specific scenarios that could arise from IT operations that have a potential negative impact on the organization.

Second, risk management recommends measures that have a mitigating effect on potential risk. It is at this point that organizations must consider the measures that are adequate and/or appropriate, since resources for implementing measures are finite and it is impossible to be 100 percent safe.

This article describes an approach that can be used to establish the correlation among operational IT risk, the appropriateness of mitigating measures and organizational targets. This, in turn, means organizations can assess organizational targets that may be exposed to risk emanating from IT operations and to what extent.

How does the risk associated with running an IT system impact organizational targets? When has an organization put in place sufficient measures to ensure an appropriate level of protection? Regardless of how many security measures are put in place to counter a risk, it is impossible to be completely safe. As a result, the key question an organization may ask is, “When have adequate, cost-effective and, therefore, appropriate controls and measures been implemented to ensure a risk does not seriously endanger the achievement of organizational targets?” Risk management is tasked with precisely providing the answer to this question.

What follows is based on the following premise: A risk scenario is manageable when adequate controls/measures have been put in place that reduce the negative consequences a potential incident will have on organizational targets to an appropriate level. Starting from this premise, this article will answer the following questions:

• What risk and/or risk scenarios can have a negative impact on organizational targets?
• What controls/measures are appropriate?

Categorizing Risk

The responsibility for effective risk management lies with organizational management. Accordingly, the challenge for risk management is to handle and summarize the numerous individual incidents of risk associated with running an IT system (referred to as operational risk) in such a way that the organization’s management team can make effective decisions regarding risk control.

One example of a risk incident (isolated incident) would be a faulty turnstile system in a data center. This isolated incident arises from the operation of an IT system and is, therefore, an operational risk. The faulty turnstile system could result in unauthorized individuals gaining access to the data center, constituting a potential risk of data and/or infrastructure theft. If an organization runs several sites with access control systems, it is highly probable that faults will occur in these systems on more than one occasion. Furthermore, when an organization is above a certain size, it no longer makes sense to report every isolated incident to the organization’s management team because the total number of incidents can be very large. For example, instead of reporting every single denial-of-service (DoS) attack to the management team, an aggregation can be reported (e.g., the number of attacks per day or month). The challenge here is how to group together isolated incidents so that the management team can use a range of aggregations to build up a complete picture of the operational risk that has been identified and, thus, make well-founded decisions.

One aim of risk management is, therefore, to stop talking about individual risk incidents at the management level and instead talk about the nature of similar incidents. It is essential to describe, group together and summarize pertinent incidents, using standardized criteria. When looking at the characteristics of a risk, it is important to consider the characteristics that will ensure a grouping produces sensible results.

Aggregating risk incidents based on the information assets (primary assets) that are affected provides an insight into the information values that are threatened by operational risk and potentially weighing which values are more or less affected. Grouping risk according to information assets brings information closer to business risk, because the IT systems (secondary assets) are excluded at the highest aggregation level.

Another option is to group operational risk according to risk scenarios. A risk scenario is the description of a potential incident that, if it occurs, will impact corporate and/or IT objectives. This impact can be positive or negative. A structure for describing a risk scenario can be found in the COBIT framework and can be used to describe organization-specific risk scenarios.

Risk Scenarios and Risk Categories

Standardization is essential to ensuring results can be compared; in this case, a standardized description of risk scenarios as suggested in COBIT 5 for Risk² is described.

A number of scenarios are defined in the framework itself. Some of these scenarios are very generic, but, nonetheless, offer guidance for describing in-house situations. The structure specifications help when standardizing scenarios. The individual structure elements have the following meanings:

• Threat—In very general terms, a threat is a set of circumstances or an incident that could result in a loss. This loss relates to a specific value such as an asset, expertise, objects or health. Transposed to the world of IT, a threat is a set of circumstances or an incident that could have an adverse impact on the availability, integrity or confidentiality of information, thereby potentially resulting in a loss for the owner and/or user of the information. Examples of threats include force majeure, human error, technical failure and intentional acts.³
• Vulnerability—A vulnerability is a security-relevant fault in an IT system or institution. Causes can lie in the design, algorithms used, implementation, configuration, operation and organization. A vulnerability can result in a threat taking effect and an institution or system incurring a loss as a consequence. A vulnerability makes a subject (institution or system) susceptible to threats.⁴ In this context, it is important to note that both a threat and a vulnerability must be present when describing a risk. For example, fire is irrelevant as a threat to nonflammable substances, due to the absence of the associated vulnerability (burning).
• Asset/resource—In general terms, an asset/resource can be described as an item of property belonging to an organization. In the case of Telekom Security, a distinction is made between primary assets (i.e., information) and secondary assets (e.g., people, buildings, IT assets).

• Time—Time plays a crucial role in the description of risk as time is, among other things, an indicator for the probability of an incident taking place.
• Threat type—A threat type describes in general terms the cause of an incident, i.e., whether an incident has been caused deliberately or by mistake.
• Actor—Who is the actor? Is it an internal employee or external third party?

The first step in aggregating operational risk incidents is to group them according to scenarios. In complex environments, the number of risk scenarios can quickly rise to three figures, making it a good idea to further aggregate the incidents. In COBIT, risk scenarios are allocated to risk categories. The advantage of aggregating into risk categories is that this classification is generic enough to be applied to any organization and the number of categories remains stable over time. This type of aggregation and the stability of categories has an enormous advantage in reporting. If category-based reporting is introduced, the number and meaning of the categories will not change significantly over an extended period. This makes it easier for the people receiving the reports to read and understand the issues that are being presented.

COBIT defines 20 risk categories (figure 1) comprising a total of 112 risk scenarios.

Figure 2 illustrates the correlation between risk categories and risk scenarios by setting out the risk scenarios for the risk category Regulatory Compliance (line 12 in figure 1).

Applying Categorization

Once the risk scenarios have been described and allocated to a risk category, this categorization can be applied, i.e., risk incidents or risk from IT operations (operational risk) can be allocated to a risk scenario.

During practical application, it quickly becomes apparent that a risk incident cannot always be allocated one-to-one to a risk scenario. A certain learning curve is required, and a series of discussions is needed to make the process of allocating a risk scenario more practicable within an organization. However, this effort pays for itself twice over, first by improving the quality of results and, second, by initiating a substantive discussion that boosts risk affinity in the organization. When operational risk is allocated to one of these risk scenarios, a picture begins to emerge. Figure 3 shows an example.

Without delving too deeply, it is clear that the operational risk can be restricted to five risk categories. The other risk categories are either irrelevant in terms of numbers, have not been found or are simply not relevant to the organization. This picture or, to put it another way, risk portfolio, initiates two key questions:

• What does the percentage distribution say about how safe the enterprise’s IT operations are? For example, are the enterprise’s operations safe enough from risk incidents in the Logical Attacks category?
• How does this risk portfolio affect the enterprise’s targets?

Defining an Appropriate Security Level

The question of what constitutes an appropriate security level in a risk scenario should be answered by the premise defined in the introduction: A risk scenario is manageable when adequate controls/measures have been put in place that reduce the negative consequences of an incident to an appropriate level.

The following hypothesis is being established as a metric for adequate controls/measures: The controls/measures are adequate when the associated control processes can be considered to meet a high maturity level as per International Organization for Standardization/International Electrotechnical Commission (ISO/IEC) 15504.

If both hypotheses are combined, the following statement emerges: The maturity level of the control processes assigned to a risk scenario is a key performance indicator (KPI) for an appropriate security level.

This statement necessitates reexamining the risk categories from COBIT. Control processes are allocated to each risk category. If these control processes have a high maturity level, it can be argued that the organization is well protected against risk incidents arising from that particular risk category. By contrast, if the maturity level is lower, there is a higher probability that the organization can expect negative consequences from risk incidents arising from that particular risk category.

Quantitative Correlation Between Organizational Targets and Security Level

Allocating risk incidents from IT operations to risk scenarios and combining these to form risk categories enables one to comment on the organization’s risk portfolio. This approach is the equivalent of a bottom-up analysis. Evaluating the control processes’ maturity level allocated to a risk scenario enables the enterprise to determine a maturity or security level. This approach is the equivalent of a top-down analysis.

The bottom-up approach delivers the relevant risk scenarios for the company. Knowing them, the organization can focus on these scenarios during the top-down analysis. The maturity level for each scenario is calculated through a self-assessment of the relevant control processes. If the standard COBIT scenarios are used, the relevant controls are the process enablers assigned to each risk scenario.⁵ The assessment can be based on the COBIT Process Assessment Model. At the end of the self-assessment of each control process for one scenario, an average must be calculated to get to one aggregated number—the maturity level. The next step is to compare the bottom-up and top-down analyses, as shown in figure 4.

In the Infrastructure Theft or Destruction category, as an example (line 14 in figure 1), it can be seen that there is real, concrete risk in IT operations that infrastructure could be stolen. Compared to the overall number of risk factors, the number of risk factors in this particular category is low. At the same time, figure 4 shows that the control processes the organization uses to mitigate the risk in this category have scored a high maturity level. In this example, it can, therefore, be said that the measures to protect against infrastructure theft constitute an appropriate security level. Nonetheless, there can—and will—be cases when infrastructure (e.g., cellphones, laptops) is stolen. It goes without saying that these isolated incidents must be analyzed and evaluated for potential improvements to be identified. However, from the viewpoint of the organization management team, there is no immediate need for action because an appropriate security level has been achieved in relation to infrastructure theft.

Once a systematic correlation has been established between operational risk from IT and the risk categories, COBIT also provides a concept for analyzing how organizational targets can be dependent on risk categories. According to COBIT, the achievement of IT objectives supports the achievement of organizational targets. In turn, risk emanating from IT operations influences the achievement of IT objectives. Therefore, the following correlations apply:

• Corporate objectives depend on IT objectives.
• IT objectives depend on risk categories.
• Risk categories are groupings of risk scenarios.
• Risk scenarios are groupings of risk incidents from IT operations.
• Risk incidents from IT operations influence organizational targets.

The following approach is used to make a quantitative statement on the dependency of organizational targets:

• Corporate objectives are linked to a revenue expectation.
• Each organizational target is linked to one or more IT objectives.
• Each IT objective is linked to at least one risk category.
• A security level (maturity level) is stipulated for each risk category.

A simplified example helps to clarify the correlations at work here. Imagine that an organization has defined six organizational targets. One of these objectives is to offer a portfolio of competitive products and services and is linked to revenue of C100 million. This particular organizational target is dependent on a ratio of one-sixth of the IT objective, “Realizing the benefits of IT-supported investment and the service portfolio.” For its part, this IT objective is dependent on the risk category, Portfolio Establishment and Maintenance. The maturity level for the control processes has been scored at just 50 percent of the specified target maturity level. If it is assumed that the other five objectives have been scored at 100 percent, then the target achievement level for the organizational target, Portfolio of Competitive Products and Services, is (100% × 5/6 + 50% × 1/6) = 91.6%. From a risk management viewpoint, approximately eight percent of the revenue target (i.e., C8 million in this example) is at risk.

Based on these workings, the organization’s management team has three choices:

1. Accept the situation.
2. Instigate immediate measures to improve control processes for the affected risk category.
3. Lower the target maturity level, resulting in a higher target achievement.

It is not possible to comment here on the most appropriate target maturity level for each risk category, as this will vary depending on how risk-averse the organization is. An organization that is more willing to accept risk will stipulate a lower target maturity level than an organization that is less prepared to accept risk.

Conclusion

Every risk incident must be subjected to a detailed risk analysis and assessment. Not even standardization will change that. Furthermore, it will always be essential that the organization’s management team is kept informed about matters in line with their importance and value. However, the standardization of operational IT risk does present organizations with an opportunity to identify systematic problems. Moreover, standardization on the basis of risk scenarios provides an opportunity to link organizational targets with risk incidents arising from IT operations. Determining the maturity level of the control processes for a risk category is a simple means of establishing a correlation between the achievement of organizational targets and risk incidents from IT operations. Clearly, this methodological approach still requires further practical evidence. However, the initial results from implementing it in organizational units at Deutsche Telekom AG gives cause to be optimistic that this is the right direction.

Endnotes

¹ ISACA Germany Chapter, IT-Governance: Zeitschrift des ISACA Germany Chapter e.V., Heidelberg: Dpunkt-Verl., Germany, 2007, p. 20-25
² ISACA, COBIT 5 for Risk, USA, 2013
³ German Federal Office for Information Security (BSI), “Glossary”
⁴ Ibid.
⁵ ISACA, Risk Scenarios Using COBIT 5 for Risk, USA, 2014