Measures for Risk Analysis and Risk Treatment

Measures for Risk Analysis and Risk Treatment
With the steadily increasing shift of value creation to the digital world, new risks inevitably arise. These risks must be identified, analyzed, evaluated, and dealt with. When applying the contents of the ISO/IEC 27005 standard, risk management forms a context-based, theoretical procedure model; freely available control frameworks and models support practical implementation up to the securing of evidence.

Measures for risk analysis and risk treatment

Initially, it is essential to know and actively manage the individual company assets. The standard distinguishes between primary assets (business-relevant processes and activities) and supporting assets (building infrastructure, people, reputation, services, hardware, software, industrial control systems, store floor systems, IoT devices, …). The latter have vulnerabilities that can be exploited by threats and aim to compromise Primary Assets.

Often, this information is already available in the form of results from a business impact analysis, various brainstorming sessions, or from business continuity management. It is important to develop the information in an unbiased and neutral manner, e.g., identifiable “knowledge and head monopolies” can represent Primary Assets – for example, if the complete administration of IT is the responsibility of one person in the company or if a member of the company management has exclusive, in-depth details about a customer or supplier relationship (“grown like this over the years since the company was founded”).

Mapping to protection goals

It is important to be able to make a sound and reproducible assessment of the impact on business operations of the loss or impairment of confidentiality, integrity and availability and possible other protection goals based on financial and non-financial parameters.

READ:  What is IT Governance?

At this point at the latest, it becomes clear that information security risk can only be one part of (overarching) enterprise risk management. One reason for this is that as the level of digitization increases, the boundaries between financial, business, and operational risks become increasingly blurred.

Threat catalogs

The “close to standard” approach envisages the use of a threat catalog. Appropriate approaches through concrete examples of the content of such a catalog are provided by Annex C of the standard, but also by other sources, such as the BSI’s basic protection catalog with the so-called elementary threats. With regard to the possible assessment of risks in connection with cloud computing, the information, and tools of the Cloud Security Alliance provide valuable support. In addition to the “internal view”, the relationship with suppliers and customers must also be considered when classifying assets, keyword 3rd party risk.

It is important that the contents of the threat catalogs are reproducible at any time, can be traced by third parties and are plausible, and are subject to constant further development within the organization. Only in this way can the targeted improvement process deliver well-founded and verifiable results.

Risk analysis

The type of risk analysis (identification and assessment) can be performed depending on the criticality of the assets under consideration or the complexity of the risk scenarios to be analyzed and must be determined in advance. The application of qualitative risk analysis uses a scale of qualifiable attributes describing the subjective extent of possible consequences (low, medium, high) and the probability of occurrence of these consequences. Quantitative risk analysis uses mathematical and financial analysis by assigning an objective value of potential loss to each component of the risk assessment. For both types, it is important to designate a person responsible for carrying out the process and to actively involve the respective asset and risk owners in the analysis process.

READ:  What is DLP (Data Loss Prevention)?

Risk handling

ISO/IEC 27005 provides 4 options to deal with risk (Avoid, Accept, Relocate, Reduce). The complete avoidance of risks can in most cases only be realized by eliminating the source(s). If the risk meets the risk acceptance criteria, it can be accepted. It may be possible to shift it, e.g., to an external, expert entity (outsourcing) or to a cyber insurance company. In both cases, it is important for the client to check and align the contractual agreements concluded with regard to the agreement of exclusion clauses and liabilities. In the majority of cases, however, the risk treatment will consist of reducing an identified and categorized risk on the basis of a risk-treatment plan. The goal is, among other things, to designate responsible parties and stakeholders, and to measurably design or monitor progress or maturity against the content/objectives of the plan.

Supporting standards and frameworks

ISO/IEC 27001 provides support in this regard with possible measures in Annex A. For example, when creating guidelines and handling security incidents, the contents of A provide support.16 In this case, “Lack of monitoring mechanisms” would be a vulnerability, “Illegal processing of data” would be the threat; possible measures are described in the article “Structured planning of an incident response readiness”.

READ:  Ransomware Attack: Acer to Pay 50 Million Us Dollars

Another information security goal could be to gradually increase the implementation or maturity level of password standards and security-relevant system configurations on Linux-based server systems. In this case, for example, tools from the Center for Internet Security can be used to describe specific hardening measures in detail.

Reliability of evidence

Organizations should move toward providing reliable and objective evidence of implementation or maturity levels of measures, especially if ISO/IEC 27001 certification may be sought. Tracking possible nonconformities from internal or external audits also set corresponding expectations in this regard. When assigning the reliability of evidence and proof, the model of the American Insitute of Certified Public Accountants can be used, for example.

In the case of the scenario described above (information security objectives of Linux-based systems), the CIS tools, aligned with the AICPA model, provide evidence beyond what may be merely verbally elicited, subjectively determined evidence:

  • Reliable, analytical evidence (open-source programs to collect relevant information on target systems).
  • Reliable, technical evidence (objectively determined, accurate number of noncompliant systems)
  • Reliable, mathematical evidence (increase in the number of compliant systems from X% to Y% in time period Z, visualization via dashboard)