The 5 elements of a good cybersecurity risk assessment

A guide to quickly improve any risk assessment

If the discussion about your risks looks like this, then you’re already doing a lot right.

There’s nothing cybersecurity experts agree on more than the necessity of a risk assessment. Every security standard requires a risk assessment, whether it’s ISO/IEC 27001, IEC 62443, or the NIST Cybersecurity Framework. Every EU security regulation requires a risk assessment, whether for operators (NIS 2 Directive) or manufacturers (Cyber Resilience Act).

And for good reason: The world is full of uncertainties, as yet unknown vulnerabilities, and an unlimited number of possible attack paths. When so much is unclear, a risk assessment is the only way to make an informed decision about necessary cybersecurity measures for a product.

If you want to apply “security engineering” in its literal sense, so if you want to make rational, fact-based, systematic security decisions, then the risk assessment is the best available tool, or in fact the only rational tool.

Companies can use a risk assessment to evaluate how effective their security measures are. This provides a foundation for deciding which security measures are important — and which are not. But also for deciding when a product or system is secure enough and additional measures would be excessive. When they’ve done enough cybersecurity.

However, not every risk assessment fulfills this promise.

I’ve been performing cybersecurity risk assessments with businesses of all sizes for ten years. I’ve written an IT Baseline Protection Profile and a PhD thesis on it, am a co-convener of the most important risk assessment standards for industrial automation systems (ISA/IEC 62443–3–2) and am responsible for a risk assessment software tool.

So I’ve seen countless risk assessments using a whole range of methods and can tell at first glance whether a risk assessment is a powerful decision-making tool or powerfully boring occupational therapy that you “just have to get through”.

This is not a recommendation for or against a particular risk assessment method or a particular standard. No method is “wrong”; you can get good results with any of them.

But there are a few criteria that distinguish a good risk assessment from a bad one. Often, there are little tricks — a change of perspective here, a different kind of documentation there — that can help transform a 1000-line Excel monster into an elegant decision-making tool. Into the tool that every security officer opens first when there’s a difficult security decision to be made, or when their team is in danger of chasing after the latest shiny cure-all.

This article is a guide to the five elements of a good risk assessment — why they’re important, what’s worth looking out for, and what expertise is required. And for each element we’ll look at a simple example.

The 5 elements of a good risk assessment

Every good risk assessment has these five elements:

1. “Real world” impacts, so everything outside of cyber systems — including an evaluation of how serious those impacts are.
2. Sufficient understanding of the architecture and functions of the cyber or cyber-physical systems being assessed.
3. Threat models, including an evaluation of their likelihood and impacts.
4. Cybersecurity requirements, including a clear rationale.
5. Reports for various target groups that explain all decisions relevant to the respective group clearly and logically.

1. Real-world impact

Why it matters

Too often, cybersecurity risk assessments take place solely in cyberspace — but this doesn’t allow meaningful prioritizing of requirements.

“Server down” is annoying, but cyber systems never exist for their own sake. That’s why risk assessments need a connection to real processes that are mission critical for the organization — or perhaps not.

This also means that risk assessments that are performed solely on the basis of vulnerability information and configurations are not risk assessments. Because there’s no way you can model the risk to an organization using this information. To do that, you need to get away from the bits and bytes and out into the real world.

What to look out for

If the real-world impact has even been considered, then the important part has already been done. Depending on the method, real-world impacts may be called high consequence events, worst case impacts, or damage scenarios.

There are two little tricks that make it easier to review them:

1. Do it right at the beginning. Real-life impacts are a kind of guiding star that provides orientation for the entire risk assessment. Time is endless and risk assessments can end up taking lots of effort — so it helps if, in the next steps, you can start by diving into the most critical impacts.
2. Involve decision-makers/C-level executives when prioritizing. It’s frequently the case that specialist departments somehow see everything as bad, while decision-makers’ priorities are more clearly ranked. So prioritizing the impacts for the organization is a good opportunity to gain decision-makers’ backing for the risk assessment. That way, everyone can be sure that the resources in the risk assessment are focused efficiently on the impacts that are the most critical from the decision-makers’ point of view. By the way, this is also a good argument for why decision-makers should spend time doing this exercise.

Who to involve

When evaluating real-world impacts, a decision-maker or C-level executive should be at the table. 30–60 minutes is enough.

What’s more, in OT it’s often helpful to get input from functional safety experts. Because they are usually used to looking in detail at real-world impacts as part of their safety risk assessments.

Example

Let’s use the assessment of a bucket-wheel excavator as an example. Below, you can see some real-world impacts and their evaluation (red = bad, green = not so bad).

If you ask people working at open-cast lignite mines what would really ruin their day, you get one answer: the excavator tipping over.

2. Sufficient understanding of architecture and functions

Why it matters

System understanding — or simply understanding that systems, whether cyber, cyber-physical or not cyber at all, should even be part of the risk assessment — makes the difference between a compliance risk assessment and a firm foundation for decision-making.

Without system understanding, there is no basis for attack modeling. Without attack modeling, there is no basis for identifying the most important requirements.

It shouldn’t really be cybersecurity’s job to create system understanding. But since there is often a lack of documentation in IT, OT, or for cyber systems in general, cybersecurity is often left to provide it. And if cybersecurity is the first team to finally create an overview of all cyber systems, then it’s a result that is useful far beyond security risk assessment.

What to look out for

1. Don’t get bogged down in the tiny details. There are lots of good reasons for an asset inventory, but it is not suitable as the only foundation for a risk assessment. The purpose of system understanding should be to gain a big-picture perspective and understand interactions between systems — only then can it help with attack modeling in the next step.
2. Create diagrams. Cybersecurity is about interactions and data flow. Architecture is important. These are all aspects that can’t be described particularly efficiently in prose.
3. Don’t be afraid to start again. Existing system documentation is mainly there to help you implement, operate, or maintain systems. But for cybersecurity you need different information. It’s an adjustment for everyone initially, but from the point of view of admins and engineers, a good cybersecurity diagram often seems unbearably simplified. However, once they’ve got used to it, they love the diagrams, because they provide an overview that the existing twelve A0-sized wall-hangings will never be able to offer.
4. Don’t forget people. Up to now, we’ve talked about information that you normally find in system documentation needing to be left out for cybersecurity. But there’s also information that needs to be added. For cybersecurity risk assessments, people and their interactions with technical systems are an essential part of system understanding, because they can be both an attack vector and a countermeasure.
5. Think in terms of functions. Functions are an efficient way to bundle all the information relevant to cybersecurity for further assessment. A function (or, for software people, a use case) answers the question, “Who does what with what, and for what purpose?” That’s all you need for the next steps: people, technical systems, interactions between them — and the reason why it all happens. An example of a function in the OT environment is programming a PLC. In the IT world, services can often be depicted as functions. Functions are a wonderful bridge between real-world impacts and business processes, which are too abstract for a risk assessment, and assets, which are too detailed for it.

Who to involve

To achieve system understanding, you need a range of roles — only with a shared perspective will you be able to gain the “big picture” overview that is so important in cybersecurity.

In IT, these may be users in specialist departments, product/application owners, or people responsible for the IT infrastructure and network. In OT, they may be plant operators, automation engineers, or the role that manages the OT network.

These people don’t all have to be in the room at the same time. Dividing the systems being looked at into functions often helps you create efficient smaller groups.

Example

For a bucket-wheel excavator, a simple cybersecurity diagram for the “Operate and monitor excavator” function could look like this. On the right are all the roles that typically need to contribute their expertise to enable the creation of such a diagram.

The goal of the diagram should be for every relevant stakeholder to be able to understand it quickly — because then everyone can also add their knowledge.

As soon as the diagram exists, you can also add the real-world impacts. They are added to the element they would have an effect on. In the excavator example, the excavator drive must be involved if there’s a cybersecurity scenario that can lead to the excavator tipping over.

Note: The photo of the excavator in the background is simply for illustrative purposes. It is not an essential part of a cybersecurity diagram.

3. Attack scenarios

Why it matters

Attack scenarios are not modeled for their own sake. The goal is not to philosophize about particularly elaborate hacker attacks. Although this may lead to fascinating academic conversations, it has nothing to do with risk assessment as a decision-making tool.

Attack scenarios are a necessary stepping stone to move your thinking from systems and real-world impacts to meaningful security requirements — no more and no less. Typical methods for identifying scenarios are STRIDE, DREAD or PASTA — or the MITRE ATT&CK framework.

A good attack scenario is so specific that identifying security requirements to avoid the scenario is simply a logical conclusion.

What to look out for

1. Work backwards from the impacts. Instead of thinking about all the things an attacker could do, it’s much more efficient to start with the most significant real-world impacts and ask how an attack could lead to them.
2. The goal is not to include absolutely everything. You don’t have to think through every possible threat scenario to make a good decision. You have to find the ones that either have very significant impacts (see point 1) or are very likely. Attackers will certainly not choose the most complicated way if there is an easier one. It’s always a good idea to ask system experts which way they would choose.
3. Stay aligned with the system. Staying specific means staying close to the system — because that’s where the impacts of an attack are felt, and where, later on, measures will need to take effect. The safest way to stay aligned with the system is to model attack scenarios directly in the cybersecurity diagrams.
4. Attack paths instead of attack trees. Attack trees are a good way to model all theoretically possible attack paths. They are also a good way to get sidetracked and lose your alignment with the system, because it’s impossible to also fit the system architecture into an attack tree. And, depending on the method, the basis for decision-making becomes diluted. For a precise definition of requirements that is as specific as possible, you need the likelihood and impacts of ONE attack path — not a complicated set of probabilities calculated using a whole tree. Keep it simple.
5. Don’t overthink risk evaluation. When talking about risk assessment methods, there’s a tendency to do a deep dive into risk evaluation. How to calculate likelihoods? Quantitatively? Qualitatively? Which levels to use for the impacts? In fact, the exact method is not as important as often claimed. Evaluation of impacts and their likelihood is a tool that helps you prioritize attack scenarios and thereby effective countermeasures. That’s it. The digits after the decimal point don’t usually change anything about the security decision.

Who to involve

For modeling attack scenarios and risks, cybersecurity expertise helps. Input from some of the system experts, too, is often valuable, but can be used selectively as inspiration at the beginning of the process or as a reality check at the end.

Example

Below is a very specific example scenario that could lead to the excavator tipping over. It has been added directly to the function diagram. Are you noticing that possible security requirements are already springing to mind?

4. Cybersecurity requirements including rationales

Why it matters

Because the purpose of a risk assessment is to find exactly the right security requirements. A security decision is always a decision for or against a security requirement.

What to look out for

1. Transparency. There are no wrong security decisions. There are only security decisions that are more or less transparent. For security requirements, transparent means that it’s crystal clear which systems (cyber or not) they relate to. It’s crystal clear which attack scenario they prevent or mitigate — and why. And it’s crystal clear why that’s important, in other words which real-world impact is at stake. Just like with the attack scenarios, the easiest way to ensure this transparency is to add it directly to the cybersecurity diagram.
2. Explicit rationale. In an ideal world, all security decisions would be based on risk. In the real world, there are also requirements that are implemented because a set of rules requires it. And there are requirements that are not implemented because functional restrictions weigh against them, or even make implementation impossible. These, too, are legitimate security decisions, but it creates great clarity if you make the rationale (risk, compliance, functional restriction) explicit.
3. Link to regulations. A security requirement can come directly from a standard, from legislation or from internal regulations. Or it can be formulated individually. The former is a good idea if you have to follow just one set of rules. If you have to follow several, it’s often easier to formulate the requirements yourself and assign them to all the corresponding requirements in the relevant sets of rules. Then, if another law comes along or a standard changes, you don’t have to fiddle with all the basic requirements, including the chain to risks and system components. You can simply revise how they are mapped.

Who to involve

Requirements can typically be prepared by a cybersecurity team, which then interviews system experts to determine feasibility.

Example

Just as with the attack scenario, security requirements are added directly to the cybersecurity diagram. That way, you can see right away which systems they need to be implemented in, and the link to the attack scenario is immediately clear.

5. Reports

Why it matters

Reports are extracts from a risk assessment that pull together relevant information from it for various target groups who lack the time and/or knowledge to understand the whole thing.

• Inform decision-makers: A risk assessment creates a well-founded basis for decision-making — but to make decisions, you frequently need approval from a third party, often someone from management or even at C-level. No manager has time to work their way through a whole risk assessment. No manager enjoys receiving a list of measures that they are expected to approve with no further context. We need something in between.
• Implement measures: If all decisions for or against requirements have been made, it’s time to move on to implementation. No problem, if you can quickly explain the requirements and how they came about to the people doing the implementing.
• Inform customers: When it comes to implementing cybersecurity, manufacturers often depend on the cooperation of their customers. That’s where an understandable explanation helps. And anyway it’s good for marketing, because it would be a shame to do all that expensive security stuff and not tell any customers. In addition, B2B customers in particular often do risk assessments themselves and are grateful for any input from manufacturers.
• Pass audits: Whether it’s an information security management system (ISMS) or KRITIS (critical infrastructure) audit, auditors and examiners want to see that the audited organization is thinking systematically about its security. It’s good if the risk assessment can be explained in understandable terms. The cybersecurity drawings from point 2 in particular are usually an auditor favorite.
• Awareness: There’s no better way to raise awareness than the understandable explanation of risks. Users deserve explanations that are pitched at their level, rather than oversimplified. When people understand guidelines, they are more likely to follow them.

What to look out for

Just one point: it should be understandable. A good report must be easy to grasp, understandable even without background knowledge, and at the same time so well-founded that it makes the security decisions transparent.

If all indicators of a good risk assessment have been fulfilled, in other words a link to the real world has been provided, a well-founded system understanding has been created using diagrams, specific attack scenarios have been modeled, and all security requirements have been developed transparently based on the diagram and attack scenarios — then creating good reports is no longer some mysterious practice. The cyber diagram becomes a cyber decision diagram — the transparent explanation of a group of security decisions on a single page.

Example

Example of a finished cyber decision diagram as a decision-making template for budgeting and implementation planning for the two security requirements.

Layered Blueprints: Think in diagrams from beginning to end

Diagrams are a recurring theme in this guide. The thinking behind this is simply that system understanding is depicted most easily in diagrams (see point 2), and diagrams are the best way to explain the results of a risk assessment to third parties (see point 5).

If you want to ensure that this system understanding forms the basis of all your security decisions, then the simplest way to do it is to stay close to the diagram for all further risk assessment steps. In other words, think in diagrams throughout the risk assessment.

At admeritia we named this idea “Layered Blueprints” a few years ago.

In the function layer (FC), you create a security blueprint to describe system functions — of cyber systems and of their impact on the “real world”. Then you overlay all the other information, layer by layer. First risks (RI layer), then requirements (RE layer).

Note: The IM layer stands for implementation. This is where requirements are translated into measures. It’s not necessarily part of the risk assessment, which is why I’m not going into it here.

Why am I mentioning the Layered Blueprint model? Because it’s a kind of fast track to implementing the five core elements of good risk assessments. If you implement the Layered Blueprints idea and nothing else, you’ll already have pinned down lots of the points in this guide.

Turn your risk assessment into a powerful decision-making tool!

If you’re not really happy with your risk assessment, don’t get hung up on the method. You can achieve good results with any method.

And don’t get hung up on who’s responsible. For the quality of the risk assessment, who performs it is not crucial (as long as the key knowledge-holders are brought in from time to time).

You can work with what you already have.

Now you know what you need in order to do that. Use the five core elements as a checklist and improve one after the other.

If you want to quickly create your first cyber diagram, try the free community tool Cyber Decision Diagrams.

And if you’re looking for software that implements all five core elements of good risk assessments, take a look at our Security Engineering Tool.