Risk Analysis
Risk analysis is the possibility that something bad happens. In IT contexts, we have cyber risk, which is the potential that a threat might exploit a vilnerability, which causes a security breach and causes harm.
IT systems are subject to threats which may have an adverse effect on the organisation's operations or assets, can effect individuals, other organisations, or national security.
This is through exploiting both known and unknown vulnerabilities which compromise CIA properties of some information during the processing, storage, or transmission of that information.
Risk Management
Risk management is the identification, evaluation and prioritisation of different risks, then coordinating and economically apply resources to minimise, monitor, and control the probability or impact of these events.
We perform several risk analysis exercises in an effort to identify, track, and mitigate risks in the software development lifecycle. Through these exercises, we can find threats, their likelihood, and impact of them, and make informed decisions about how to mitigate them.
Risk analysis is the overarching concept that encompasses several risk analysis methods, which are found through an identification or evaluation of those risks.
We have assets, which a threat wants to exploit through a vulnerability. This constitutes a security risk. We need to introduce some security mechanism to protect this asset, to reduce the overall risk level.
Definitions
- Vulneratbility--weakness that could be exploited by a threat
- Threat--entity exploiting a vulnerability
- Threat Event--event or circumstance with potential adversely organisational assets
- Likelihood--probability that a threat event occurs
- Adverse Impact or Consequence--magnitude of harm caused by a threat event
- Risk--function of likelihood and impact or consequence
- Treatment or Countermeasure--a measure to reduce the risk level
Risk Analysis in Software Development
This relates to the requirements and use cases of software, in addition to the architecture and design of the software. We develop requirements and model the system as part of the system design, then perform threat analysis and mitigations based on these models.
Threat Modelling
This is an activity in the SDLC which occurs early on, and reviews the features and architecture of the product in a systematic way from a security point of view. We then identify threats and derive mitigations for these threats.
These mitigations are context-specific. Modelling can be done on different levels of abstraction, so it is appropriate for a multitude of different systems.
Overall Process
The overall process is as follows:
- context identification
- risk identification
- risk estimation
- risk evaluation
- risk treatment
Context Identification
This allows us to characterise the target of analysis, giving the focus and scope of the analysis. We then identify and give value to the assets. We can define the likelihood scale and description, a consequence scale for each asset, then specify the criteria for the risk evaluation, e.g., what is the client happy to tolerate.
Likelihood Scale
Likelihood can be categorised by the following table:
| Likelihood | Description |
|---|---|
| Certain | 5 times or more per year |
| Likely | 2-5 times per year |
| Possible | once a year |
| Unlikely | less than once per year |
| Rare | less than once per 10 years |
Consequence Scale
| Consequence | Description |
|---|---|
| Catastrophic | Very significant impact. Legal or regulatory implications. Significant reputational impact. |
| Serious | Major effect, may lead to significant delays |
| Moderate | Moderate efect, may lead to some delays |
| Minor | Some impact of the risk, fairly minor |
| Insignificant | Fairly insignificant, may lead to a tolerable delay |
Risk Evaluation Matrix
We can create a risk function between the impact and the likelihood of the risks, assigning a score to each element.
Risk Identification
This is the process of identifying threats to assets through brainstorming. To do this, we bring in system owners, users, developers, domain experts, and risk analysis experts.
We then identify the vulnerabilities of the assets by going through questionnaires and checklists (e.g., check equipment is physically protected against unauthorized access to data or data loss)
Risk Estimation
This is the process of determining the level of each of the identified risks. We assign each threat event a likelihood value and an impact value, as defined above.
The assessment of a likelihood value is normally based on the adversary intents, capabilities, and targeting, and is based on historical evidence, empirical data, or other factors.
Assessments of the impact is based on the harm that we expect from the threat event, and the range of effects of the threat, including the relative size of the set of resources affected.
Risk Evaluation
Risk can be assessed quantitatively, qualitatively, or semi-quantitatively. We then map the risks into a risk evaluation matrix.
When evaluating risks, we need to understand that we cannot completely eliminate all risks, and that we will only be able to treat a subset of the risks. We prioritise the more serious risks.
Quantitative vs Qualitative vs Semi-Quantitative
Quantitative assessments use numbers, e.g., cost-benefit analysis of alternative risk responses or courses of actions. The meanings of these analyses may not be clear and will need interpretation.
Qualitative assessments are used to communicate risk results to decision makers, but due to the inherent subjectiveness, we may yield substantially different results from different analysts.
Semi-quantitive makes use of both qualitative and quantitive methods to categorise risk into bins or scales, which we can then assign a qualitative owrk to.
Uncertainty
When evaluating risk, there is some inherent uncertainty built in. This could be due to limitations in how the future resembles the past, imperfect knowledge or the threat, undiscovered vulnerabilities in technologies or products, or unrecognised dependencies, leading to unforseen impacts.
The degree of undertainty should be communicated in the results in qualitative ways by providing ranges of values or fuzzy regions instead of concrete points.
Priority
Risks with the greatest loss and the greatest probability of occuring are handled first. Lower probabilities and lower loss risks are then handled in descending order.
The process of assessing overall risk can be difficult, and we need to balance resources used to mitigate risks with high probability vs low loss vs risks with high loss but a lower probability.
Risk Treatment
Risks can be split into four options: accept, treat, avoid or terminate, or transfer.
We need to identify a combination of these or a specific option to apply, then evaluate and prioritise treatments for different risks.
Standards
The following standards are used for security analysis:
- International: ISO 27001, ISO 27005, ISO 31000
- National: IT-Grundschutz (Germany), Magerit (Spain)
- Standards-based: OCTAVE, CORAS