When working with cybersecurity and segmenting your systems into security zones, it is a good idea to use risk analysis. In this way, you can avoid that the security work is carried out according to an undefined “ad hoc” method. In addition, it is often easier to explain and justify the investments you want to make if you can account for the risks you handle or reduce. The standard IEC 62443 is a good method to use when doing your risk-based zoning.
In this text, we explain in detail what is important to keep in mind when conducting a risk analysis and risk-based zoning according to IEC 62443.
Why do you do a risk analysis?
In order to know in which direction to go with your cybersecurity work, you must evaluate the business as it is today – by making an analysis of the risks that currently exist in the business’s system.
An initial, simple risk analysis identifies the worst that can happen today without having introduced any risk-reducing measures. Later, a detailed risk analysis is performed for separate zones and flows. This step is taken when the groupings of zones and flows have been made, based on the initial risk analysis.
The goal of these risk analyses is to ultimately be able to apply the right risk-reducing measures and create a more secure business where focus is put in the right places.
How do you do an initial risk analysis?
In the initial, simple risk analysis, you look at a worst-case scenario, i.e. the worst that can happen to the business. Here it is assumed that no measures have been taken to reduce the risks that exist. You need some input in this phase, such as:
- Overall system architecture – you need to know which systems are included in order to systematically go through them.
- Risk criteria and risk matrix with tolerable risk – what risks can we accept, and which do we have to do something about? How do we measure risk?
- Existing risk analyses – have we done any kind of risk analysis before, and can we use parts from there?
- Information about what threats that exist – what could happen? What are the threats to the organisation?
The above is an example of a risk matrix where you can easily see how serious a risk is depending on the consequence and probability. In this example, it has been decided that:
- Tolerable risk, a risk you are willing to take, is turquoise.
- Significant risk, a risk you should perhaps do something about, is medium blue.
- Non-tolerable risk, a risk you have to do something about, is dark blue.
Based on this input, it is possible to calculate a worst-case risk to which the various parts of the system are exposed without security functions or segmentation. The question is, what effect does a cyberattack where the systems are put out of play have on the business? What would the magnitude of the attack be? How large geographical areas would be impacted and how many people would be affected? If electricity distribution was to be shut down, many people would feel the effects. Are there critical activities (e.g. hospitals) that are dependent on electricity supply? In the initial risk analysis, you are only interested in the consequence and then you assume that the probability is ‘often’, which means that you will move in the right-hand column in the figure above.
By defining our different worst-case scenarios and connecting these to the different systems, we can make an initial zoning where the systems are placed in zones together with other systems with the same level of risk.
How do you do a detailed risk analysis?
After the initial risk analysis, a grouping of zones and data flows is made. You can read more about how to use zoning in our blog post!
Once you have made this grouping, you can do a detailed risk analysis. According to IEC 62443, a detailed risk analysis is performed if the initial risk exceeds the acceptable risk. In the detailed risk analysis, one risk analysis is performed per zone and flow and is based on the same risk matrix as for the initial risk analysis. The detailed risk analysis is based on a number of steps:
1. Identify threats and threat actors against zones and flows
In this step, you identify which threats and threat actors that can affect your zones and flows. This requires knowledge of threats toward the business – here you can use external monitoring. You can look at several different sources, including MUST and Säkerhetspolisen. Also, this is something that the organisation’s head of security should be aware of.
2. Identify vulnerabilities that can be exploited
The next step is to identify vulnerabilities where the purpose is to find possible weaknesses or “holes” that can be exploited. There are a number of sources you can use to find potential vulnerabilities:
- Network architecture: Which access points are there, and what paths lead to the internet?
- Traffic analysis: Reveals traffic that should not be there. Are there products that communicate with the Internet that should not do this
- Penetration tests: Often performed by external experts.
- Vulnerability scan: Can also be performed by external experts.
- Security policies: Are they up to date with relevant threats?
- Security-critical staff: What security-critical staff is there and what is there in the form of instructions, processes, training, and background checks? Note that many attacks are made because of mistakes by own staff.
- Interview staff: Staff often has a lot of information about security flaws that they have identified.
3. Assess unmitigated consequence, probability, and risk
Then you have to assess unmitigated consequence, probability, and risk. The combination of probability and consequence results in a risk that is mitigated/decreased by a certain measure. An unqualified risk is thus a combination of probability and consequence before we have introduced one or more protective measures. Examples of types of consequences are:
- Personal security
- Economic impact
- Interruption of operations
- Environmental impact
- Downtime, damage to equipment
Once you have analysed the consequences that could occur, you must examine how likely they are. It can sometimes be difficult to predict, but here are some things to keep in mind:
- Has it happened before?
- Have other, similar activities been affected?
- How attractive is the asset?
- How exposed is the asset?
- Is it a constant threat? Constant threats tend to occur more often.
- How motivated and well-funded is the threat agent?
- Physical security and other functions in the system that can reduce the probability are taken into account, e.g. a security valve or working methods/procedures.
When both consequence and probability have been calculated, one can use a matrix, for example the matrix mentioned earlier, to calculate the unmitigated risk.
4. Introduce risk-reducing measures
The next step is what measures you can take to reduce your risk. Risks can either be mitigated (by introducing measures), transferred to someone else (e.g. by insurance) or accepted (we live with it and hope it does not happen). If you choose to mitigate the risk, you must continue to work towards introducing appropriate measures.
Standard IEC 62443 defines a “staircase” of so-called security levels. There are five levels – on these levels, your zones and flows can be placed. The purpose of the five levels is to be able to communicate this in a clear way to those who design, implement and maintain IT security. This means that you can say that “this zone is on security level 4” and thus you know a number of things, which according to the standard, must be conducted.
According to IEC 62443, these points can be used to define the level on which a zone or flow should be placed:
- Difference between unmitigated risk and acceptable risk – if there is a big difference between these, the security level must be raised.
- According to the definitions of security level in IEC 62443.
- By “guessing” and redoing the risk analysis with mitigating measures and possibly adjusting the security level.
It is common to work iteratively and “guess” the security level, redo the risk analysis, and then compare the remaining risk with the acceptable risk. From the security level, you can later obtain the security requirements that must be met.
5. Assess reduced consequence, probability and risk
When the measures are introduced a new risk assessment is made, but this time with the measures included. The remaining risk is accepted, mitigated or transferred. It is important that management bears the remaining risk. That is, management must be involved in the decision to accept or introduce more measures.
6. Is the reduced risk OK? If not, introduce more measures
If the goal is not reached (the goal is having only acceptable risks left), further measures must be introduced. When the reduced risk is less than the acceptable risk, you have reached your goals with your risk-reducing measures.
To mitigate your risks, various measures can be required. Advenica offers several solutions for your cybersecurity – read our solution descriptions to learn more about what we can help you with!
Want to know more about IEC 62443? Read more here!
Do you want to read more about how to make a secure IT/OT integration based on IEC 62443? Read our blog post!
