More aspects of managing risks¶
Parts or the whole?¶
The whole and its parts are usually a continuum, but in risk management it is also useful to understand the differences between extremes: Component-driven risk management (bottom-up) focuses on technical components and their threats and vulnerabilities. System-driven risk management (top-down) analyzes the system as a whole.
Component-driven and system-driven risk management complement each other. The system-driven approach defines the overall objectives and what is not intended to be done. It helps to better understand the complexity and factors behind interactions between different system parts. These may include, for example, people, technology, and organizational processes, whose interactions and dependencies are not trivial. The component-driven approach examines, for example, which capabilities and functions are needed to achieve the system’s goals and considers the impact of risk realization on individual system components (e.g., hardware, software, data, personnel).
Component-level risk management methods are suitable for:
- analyzing the risks of individual technical components.
- breaking down less complex systems when connections between components are clear.
- working when the physical operation of the system has already been agreed upon among stakeholders.
System-driven risk management methods are suitable for:
- defining system security requirements before decisions about physical characteristics have been made.
- bringing together the perspectives of several stakeholders on what the system should and should not do (e.g., physical safety, information security, legality).
- investigating security incidents, which result from interactions of several system parts and which cannot be traced to a single point of failure.
Component-level risks are likely more relevant to operational workers, for whom component functionality is essential to perform their tasks and achieve goals. System-level risks are more relevant to managers who make decisions about the system’s overall strategy. The challenge is to combine these perspectives into effective risk management that everyone can commit to.
Elements of Risks¶
At this stage, it is worth clarifying a little what constitutes a risk, whether it concerns the system or its components.
- Vulnerability
is a weakness that can be attacked or misused. If a vulnerability is exploited, it can affect a process or system. Vulnerabilities can be diverse and involve
- technology: poorly designed or buggy software, a user interface accepting invalid input, etc.
- people: inadequate employee training, business suffering from lack of personnel, etc.
- organizations: poorly articulated operational processes, insufficient investment in protections, etc.
- and have legal implications: e.g. a data leak from a poorly managed database may lead to large fines.
This is not a complete list of what a vulnerability can be, but it highlights that vulnerabilities are sociotechnical—often involving both people and technical systems.
- Threat
- is a person, event, or action capable of exploiting a vulnerability. Also threats are sociotechnical and may include hackers of all sorts, dissatisfied employees searching for revenge, negligent actions by users (e.g. falling victims of phishing), accidental mishandling of data because of wrong or outdated instructions, losing availability because of failing storage media or running out of electricity. The last two examples show that the vulnerability behind threats can be of rather general kind and not necessarily appearing in analyses.
- Likelihood
- is a measure of how probable it is that a threat exploits a vulnerability and causes an undesirable outcome to the value of the protected asset. Likelihood may be qualitative (low, medium, high) or quantitative (e.g., a scale from 1–10 or a percentage). Note that the concept of exposure may appear here in determining whether, and how easily, threats can come into contact with vulnerabilities.
- Impact
- is the consequence of a threat exploiting a vulnerability, negatively affecting the objectives related to the assessed risk. Impact depends on perspective: from a system-wide perspective, the impact of a realized risk might be that a new product is not ready on time, whereas from a lower level perspective, the impact might be that a single component breaks.
Systems for risk management¶
There are several standards and guidelines for risk assessment and management. Their goal is to provide a systematic way to transform vulnerabilities, threats, likelihoods, and impacts into an organized list so that risks can be prioritized and addressed. Each standard has its own characteristics, but they also share common features. These shared features are shown in the figure below.
- Pre-assessment identifies the risk, actors and stakeholders involved, and relevant perspectives.
- Appraisal (also: risk and concern assessment) evaluates the causes and consequences of the risk and develops understanding of risks and mitigation options (e.g., prevention, sharing).
- Characterisation and evaluation determine the significance of the risk and how much risk can be tolerated.
- Risk management involves decisions about the risk management plan and its implementation, including risk tolerance: If a risk is not accepted, then it must be either avoided, mitigated, shared or transferred. The last two mean that someone else becomes partially or fully responsible for the damage. Ordinary cybersecurity measures usually do mitigation.
All four phases include communication, stakeholder engagement, and contextualization through open and participatory dialogue (as shown in the center of the figure). It is important to note that risk assessment and management is an iterative process, which must be carried out continuously as circumstances and operating environments change. When security incidents occur, it is important to learn from them and improve risk management, and also security policies as part of communication.
Standards and guidelines for risk assessment and management include, for example, NIST SP-800-30 and ISO/IEC 27005. The diagrams below show their processes. Both include phases corresponding to those above.
NIST SP800-30 and -39 are risk assessment and management methods used by the U.S. government and federal agencies. They provide clear guiding phases to support the entire risk assessment and management process, from contextualization to risk tolerance and effective oversight. They are publicly available and aligned with ISO standards.
ISO/IEC 27005:2018 is an international standard for information security risk management. It does not specify a particular risk assessment technique. The standard emphasizes component-level assessment and requires the definition of vulnerabilities, threats, and impacts.
Risk Assessment and Management Methods in Cyber-Physical Systems¶
In traditional information security, that is, in the world of desktop computers, servers, and other devices, risk management usually aims to minimize access, data alteration, and service interruptions within components and systems (that is, to promote confidentiality, integrity, and availability). In cyber-physical systems and operational technology, more attention is usually paid to physical security. Cyber-physical systems are, for example, industrial automation control systems that are part of critical national infrastructure (such as energy supply, logistics, and water treatment). They can also be complex industrial manufacturing systems where the processes are too heavy, monotonous, or dangerous for human workers. Risks are often related to safety or operational reliability since the direct impact of the systems on the physical world exposes workers, other people, or societal functions to danger. Therefore, system-based methods should be used in risk assessment and management, with high-level objectives as the starting point (e.g., avoiding death, complying with regulations). In this way, the perspective of physical safety is taken into account.
Nowadays, cyber-physical systems are increasingly desired to be used, for example, remotely, and they also require the perspective of traditional information security. In this case, it must be taken into account that remote access, for example over a network, introduces all network-related risks into cyber-physical systems. Historically, safety-critical systems have had significant global impacts when control systems have failed (e.g., Chernobyl, Fukushima). With the connection to the network, elements of global political risk and highly resourced attackers (e.g., Stuxnet, BlackEnergy) also come into play. In addition, for example, IoT devices are a newer interface to safety-critical systems, and they can provide a window through which attackers gain access to the system. IoT security is still immature, and the impact of IoT devices and the perspective they bring to risk management is not yet fully understood. More on cyber‑physical systems can be found in this module.
Measuring Security (advanced)¶
Security metrics have long been debated because security is often difficult to quantify. Qualitative assessments are typically used when reliable quantitative data is lacking. The problem with qualitative assessment is that scales such as red-yellow-green are subjective and mean different things to different people and stakeholders. Open questions in measurement include: which system characteristics should be measured in relation to risks, how to measure risk, and why measure risk at all? Some metrics may relate to risk levels, some to system performance, and others to service delivery or reliability.
Metrics have different characteristics, but something general can be said. Good metrics are said to
- measure consistently, without subjective criteria.
- be easy to measure and collect, preferably automatically.
- be expressed as numbers or percentages, not qualitative labels (e.g., low-medium-high).
- use at least one unit of measurement, such as “errors”, “hours”, or “euros”.
- be relevant to the context and meaningful to decision-makers so that actions can be taken based on them; if the reaction is a shrug and “so what?”, it is not worth measuring.
The more of these properties metrics is missing the worse it is.
Metrics should be based on the understanding that perfect security is impossible, so measuring actual security against necessary security is an acceptable approach. This allows metrics to be tailored to measure the effectiveness of vulnerability management. It is particularly important to consider whether it is possible to measure numerically that the risk management plan and its security controls are appropriate against identified threats, and whether the metrics provide real evidence that the chosen controls are correct. Additionally, one should consider whether the chosen controls are cost-effective—that is, whether they provide more value than their implementation cost.