Last updated at Mon, 08 May 2023 19:28:54 GMT
Synopsis
Information security risk management is a wide topic, with many notions, processes, and technologies that are often confused with each other.
In this series of articles, I explain notions and describe processes related to risk management. I also review NIST and ISO standards related to information security risk management.
In the previous article, I reviewed the tiered risk management approach described in NIST Special Publication 800-39: “Managing Information Security Risk: Organization, Missions and Information System View”.
In this article, I will start describing the context establishment phase of the information security risk management process.
The risk management strategy
The end result of context establishment phase is detailed information security risk management strategy. No risk management activities should happen without such document.
Unfortunately very often technical “risk management” solutions are implemented without such strategy. If this happens, it is very probable that such solutions are not aligned with organization’s mission and high-level risk management approach. It is also probable that many risk-related parameters are not set and, as a result, no proper decisions can be made based on the output of such implemented solutions. This, in turn, means just the false sense of security.
The risk management strategy should explain how an organization:
- assesses information security risks;
- treats/responds to such risks;
- monitors risks.
NIST SP 800-39 lists four tasks in this phase (which, by the way, is called “Risk Framing” in this guide):
- identify assumptions;
- identify constraints;
- identify risk tolerance;
- identify priorities.
Information security risk management assumptions
The risk management assumptions allow for execution of risk assessment. The main assumption is the risk assessment methodology. An organization needs to wisely choose the risk assessment methodology. Such methodology should be appropriate for specifics of the organization or should be flexible enough to be adapted to such specifics.
Vulnerability, threat, incident, and impact
The risk assessment methodologies are based on the following notions:
- vulnerability,
- threat,
- consequence/impact.
It is important to understand definitions of all three.
A vulnerability is an internal characteristic of a process or resource. On the contrary, a threat is something that comes from the outside of resource or process. These two notions are often mixed up which makes risk assessment much harder.
Examples of vulnerabilities:
- unpatched operating system;
- unencrypted file;
- no backup administrator for server XYZ.
Examples of threats:
- a possibility that a hacker exploits the unpatched operating system;
- a possibility that unauthorized person will read the unencrypted file;
- a possibility that the administrator of server XYZ will get seriously sick.
General correlation is that a threat can exploit a vulnerability, which will cause an incident with specific consequences.
Please note that a particular threat itself (e.g. a hacker) is no danger if there’s no vulnerability to be exploited (e.g. unpatched operating system). In practice, of course, such cases are rare. But what is very important is that correlation vulnerability-threat should be taken into account in risk assessment methodology, because both of these factors influence final risk level for particular risk scenario / process / resource.
If a threat exploits a vulnerability, an incident happens.
Each incident has its consequences. The consequences of an incident should be taken into account when calculating risk level. This is because the “seriousness” of these consequences can be significant for the affected business process, but can also be minimal (neglectable).
For example, if an unauthorized person (threat) reads (incident) an unencrypted file (vulnerability), but the file contents is some outdated information, there will be no impact (consequences) on current business processes and there will be minimal (or none) general business impact of such incident.
There are additional factors that influence final (so-called “residual”) risk level – these are activities undertaken to:
- reduce the probability of an incident (e.g. security measures);
- reduce the impact of an incident (e.g. recovery measures).
I will get into more details on that later.
When working on information security risk assumptions and choosing risk management methodology, remember about the above remarks and correlations.
Information security risk management constraints
The risk management strategy should explicitly address the risk management constraints. These can be of operational, financial, regulatory or other nature. For example, the financial constraints might limit budgets for risk reduction. The operational constraints might not allow for risk assessment to be conducted more than once per certain period. The regulatory constraints might not allow for full risk assessment to be conducted in a foreign branch.
Information security risk tolerance
Just as an organization needs to define tolerance to other types of operational risk (e.g. financial risk, reputation risk), it needs to define the tolerance to information security risk.
The risk tolerance is defined on three levels, related to three tiers on which information security risk management is conducted.
On the organizational level, the information security risk tolerance level should result directly from operational risk tolerance levels.
On business process levels, the information security risk tolerance levels should be calculated in a way so that the impacts of business processes disruptions do not cause consequences that would exceed the tolerance defined on the highest (organizational level). Definition of tolerance thresholds on business process level will not be possible without the precise definition of business processes.
The tolerance thresholds on business process levels should, in turn, be translated to risk tolerance matrices for specific information processing resources used for each process.
In practice, the risk tolerance will most probably be expressed by the set of so-called risk acceptance matrices for each risk management tier.
With the use of proper risk management methodologies, parts of the process of decision making related to risk tolerance can be automated. But final decisions will always be made by humans.
Next article
In next article, I will get into more details of the information security risk management cycle context establishment phase.
References and further reading
Information Security Risk Management – Introduction
Information Security Risk Management Cycle – Overview
Information Security Risk Management – Tiered Approach of NIST SP 800-39
ISO 31000:2009: “Risk management — Principles and guidelines” (currently under review)
ISO/IEC 27005: “Information technology — Security techniques — Information security risk management”
NIST SP 800-39: “Managing Information Security Risk: Organization, Missions and Information System View”
NIST SP 800-30 Rev 1: “Guide for Conducting Risk Assessments”