februar 16, 2024
After having described the context, the next step in risk management is to take a closer look at the “values” – also called “assets”. The first step in this subprocess is to define the system/area being analysed and map the assets present, to enable further examination of each individual asset.
In essence, risk management focuses on creating an overview that will facilitate informed decision-making. Prior to the actual risk management, the first step is to identify the assets, after which potential threats to those assets can be evaluated. The purpose is to establish the necessary overview of assets that will serve as the foundation for the risk assessment.
To identify various risks in the system, one can examine the elements in the system that have or create value. In general, the easiest approach to identifying assets is to organise a workshop lasting a couple of hours (depending on the system to be analysed), followed up by some descriptive tasks if needed.
The process of mapping the assets can be divided into two parts: scoping and brainstorming, both of which will be elaborated in the following sections.
Generally, it is advisable to strive for diversity in this process, ensuring that both individuals with business understanding and technical insight participate. If, for example, only technical experts are involved, there is a risk of missing important business aspects. On the other hand, businesspeople may not necessarily possess the required technical knowledge about how the system is built, which could lead to unintentional omissions here as well.
In the previous step, context establishment, a number of stakeholders were described. The list should include all relevant individuals, but if a risk assessment is carried out for the first time, the list may have to be revised.
The process of mapping assets follows three overall steps. Each will be described in more detail in the running example after this guide.
After the brainstorm, the list of assets must be consolidated. You may have to describe some of the assets in more detail, only to realise that they are already included in another asset. Then compare the list with the system diagram to ensure that everything has been included. Find more inspiration in the IoT door lock example below.
Below is an overview of stakeholders from the tool establishing context.
To make sure that all participants in the workshop are aligned as to what is being analysed, it is advisable to agree on some common definitions. The context description already provides an overall delimitation/definition of the system, but it may be a good idea to revisit and refine the description if needed. If there are architectural diagrams or other technical descriptions available, they can also be a good starting point. However, be aware that architectural diagrams typically contain a lot of information and can be challenging for non-technical individuals to understand.
If such material is not available, you must start from scratch. It is advisable to keep the diagram relatively abstract to begin with and focus only on the major components. For example, it is not uncommon for a client and a server to communicate with each other in different ways (REST, WebSocket, etc.), just as the server internally may consist of various microservices. Including all these details in the diagram could quickly become a bit overwhelming. After all, this information is not needed until the threat modelling process. Instead, the emphasis should be on the major components, and the communication between A and B can simply be marked on the diagram.
When drawing the system, you can for instance start by sketching a user. The user may interact with a mobile app, a laptop-based web app, and the IoT device itself. Once the initial elements are in place, it usually becomes easier to finish the rest.
The example shows a connected network of hardware, software, and communications systems, including IoT door lock hardware with a communication module, an IoT hub, a mobile application for remote access, and a cloud infrastructure for data storage and processing.
During the workshop, you may identify components that you are uncertain whether or not to include in the diagram. For instance, if your system transmits data to third parties through an API, you may be uncertain whether the third-party system should also be included in the diagram. However, the purpose of the scoping process is to have such discussions and document the outcomes. This ensures that assumptions and boundaries are explicit for everyone, preventing later decisions from being based on incorrect assumptions.
When working with risk management in general, “assets” can encompass a lot of things, from buildings and facilities to employees and knowledge. When dealing with risk management in IT and cybersecurity, it is advantageous to consider “assets” as data. The main reason is that the method described in the following for assessing the consequences of an incident is best suited for information/data and less suitable for physical objects. There may of course be physical items in the system that also need protection; for example, if a sensor is expensive and can be stolen, but this will not be covered by this analysis. Hence, a server or a laptop is not considered an asset, whereas the data stored on the server is.
In some cases, the “general asset” may be covered by the term “information asset”, which is a more appropriate term in the context of IT and cybersecurity.
Once the diagram of the system has been created, and you agree on the contents, the next step is to identify the assets. As a starting point, a brainstorming session is conducted where findings are noted. However, to make the brainstorming process more structured and ensure that nothing is overlooked, a number of methods can be employed:
Method A: Technical and business assets:
Using this approach, individuals with business insight describe the data that customers and other stakeholders receive/want, what the data is used for, and what is needed to generate this data. At the same time, technical experts examine the data present in the system. This includes what is stored in databases/file systems, data retrieved from external partners, data sent to clients, etc. The two lists can then be consolidated into one.
Method B: Follow the system diagram:
Another option is to follow the diagram you have just created. Consider what role each component in the diagram plays and the data associated with each process. In the scenario of a client application accessing a backend, you can for instance examine the client functionality and the data exchanged in that context. This includes components such as username/password for system access, the ability to view devices (and their measurements) linked to the account, the ability to register new devices, and the capability to activate or manipulate a connected device in some way.
Download example: Information-centric asset list for IoT door lock system.
Once you have completed the brainstorming process, the next step is to consolidate the findings. If method A was employed, the list of technical assets will be relatively long and include very specific data.
Many of these assets can be described at a more general business level if preferred. For instance, "invoices," "orders," "complaints," "contact information," and "delivery address" can be described as "customer data" without losing essential information.
Moreover, it can be a good idea to utilise both approaches to ensure a thorough representation. Even if you think you have covered the entire system, you may discover a component in the diagram that seems not to contain any assets. On the other hand, you may realise that the diagram lacks components that are essential for a vital functionality in the system. In both cases, it is crucial to ensure that the diagram accurately reflects reality.
Generally, it can be challenging to find an appropriate level of abstraction. Firstly, because it might not be relevant to distinguish between components that one initially perceived as distinct assets. Secondly, there is a risk of defining an asset in such broad terms that further elaboration would require different versions depending on the context in which the asset is analysed.
The outcome of the process is a list of assets that are vital for the system. These assets represent the information that enables the system to function and create value. The list of assets is used in the subsequent analysis, where the focus is on examining the consequences if an asset is compromised.
In principle, the list can also be used alongside a list of security mechanisms to investigate how the assets are protected.
Generally, it will often be necessary to involve people with technical knowledge of the system in this process. People with business understanding are skilled in identifying conceptual assets but may not have a full understanding of the "invisible" assets that make the system work. Technical experts can provide valuable contributions and identify assets that might not have been discovered otherwise.
It is also advisable to include too many assets than too few at this stage. An asset can always be removed later if it turns out to be irrelevant, but if an asset is left out at this stage, it will not be analysed later; hence, the entire system may not be covered.
In the consolidation and verification stage, it is advisable to have the list verified by individuals who were not directly involved in the brainstorming. If they have questions regarding some of the final descriptions, some elements may have been overlooked.
After having mapped the assets, the next step is to analyse the consequences if an asset is compromised in terms of confidentiality, integrity, and availability. This is described in more detail in the analysis of assets impact.
The contents described above have been developed in the project:
’CyPro – Cybersecure manufacturing in Denmark’ by Aarhus University, Alexandra Institut, DAMRC, UGLA Insights and FORCE Technology funded by The Danish Industry Foundation. Material from the project is published under licence CC BY-SA 4.0
