The module - in brief

After having established the context (link), the next step in risk management is to model the system under assessment. The outcome of this process is the system architecture and/or data flow diagram. 

Purpose of system modelling 

The second step in risk management is system modelling. The step includes making a model of the system (or product) that is being assessed. 

The purpose of system modelling is to identify the elements that form the system and their connections. This process lays the foundation for achieving a common understanding of the system under evaluation and enables to reason about data flows between components. The architecture can be described at various levels of detail, depending on the task at hand. 

Practical information

Prior to identifying the threats, we need to define the system we want to assess, including related components and their interconnections.

System modelling is usually conducted as a workshop, often supported by purpose-made tools. In case you do not intend to use any specific tools, you will need a whiteboard/flipboard along with coloured markers, stickers, pens, and printed versions of the worksheet. It is recommended to carry out the discussion using paper/whiteboard rather than a computer, so that all participants have the opportunity to be involved.

When assessing an existing system/product, it also pays off to review the existing design documentation and refer to it throughout the assessment.

Allocate at least an hour for system modelling. It is recommended to strive for diversity in this process, ensuring that both individuals with business understanding and technical insight participate. 

System modelling

An important part of the risk management is to have a clear picture of what we want to analyse, i.e., the full overview of the system architecture. This overview will facilitate the discussion about the assets and threats.  

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 establishment 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. Hence, to ensure that all participants have an understanding of the system, it is advisable to create a relatively abstract drawing from scratch  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 later steps (Asset analysis and Threat identification). Instead, the emphasis should be on the major components, and the communication between A and B can simply be marked on the diagram. 

Step-by-step guide

The process of drawing the system model follows the following steps:

1. Identify the components
   Brainstorm about the elements that form the system. Consider both internal and external elements.
2. Identify interactions between components
   Map how the elements in the system interact. 
3. Understand the data flow
   Brainstorm about the data required for the system to work. Understand how data flows across different components and where data is located and stored. This may result in the addition of new components, or existing components may be merged into a single component.
4. Mark a trust boundary
   Identify the trust relationship between the components. A trust boundary is used to denote the point at which a trust relationship exists.  
   The components can be grouped together into a trust boundary, e.g. when it runs on the same server. We can also use trust boundary to isolate single components, e.g. an external entity. 

Find further inspiration in the IoT door lock example below. 

IoT door lock example

Let’s investigate our IoT door lock example that we use as a running example throughout the risk management process.

The example consists of an interconnected network of hardware, software, and communications systems, including the IoT door lock hardware with a communication module, a hub, a mobile application for remote access and a cloud infrastructure for data storage and processing. 

1. Identify the components 
   Here, we brainstorm and list all the components that form the IoT door lock system. We identify internal and external elements, such as:
   • IoT door lock: The primary hardware installed at the entrance, equipped with a communication module and locking mechanism.
   • IoT gateway: A physical device that acts as a hub, connecting the door lock to the cloud to enable seamless communication.
   • Cloud servers: The infrastructure deployed and managed on a cloud hosting solution to process, store, and handle data.
   • IoT applications: The software interfaces used by end users to control and monitor the system.
   • End users: Individuals who interact with the system through the mobile app or physical device.
   • Business systems: External systems that integrate with the IoT platform for monitoring, analytics, or operational needs.
     
     
2. Identify interactions between components 
   Next, we map out how these components interact with each other. For example:
   • The IoT door lock sends and receives commands through the IoT gateway.
   • The IoT gateway acts as a bridge, transferring data to and from the cloud servers.
   • The cloud servers process data and communicate it to the IoT applications for user interaction.
   • End users use the applications to send commands or monitor the system.
   • Business systems interact with the IoT applications to enable advanced features such as access monitoring or reporting. 
     
     
3. Understand the data flow
   Here, we determine how data flows between components and where it is stored. Key flows include:
   1. From IoT door lock to IoT gateway: Data such as lock status, battery levels, and security alerts.
   2. From IoT gateway to cloud servers: Logs (such as access logs, system logs and diagnostic logs), security alerts, commands, and system updates.
   3. From cloud servers to IoT applications: Processed information, real-time updates, and notifications for users.
   4. Between IoT applications and business systems: Data exchanges for analytics and broader system integration. 
4. Mark a trust boundary 
   Finally, we identify trust boundaries to delineate areas of trust relationships. For instance:
   • The IoT door lock and IoT gateway share a trust boundary as they are part of the same local network (presented in the picture below). Note, that we assume that the gateway is integral part of the system.
   • Communication between the IoT gateway and cloud servers crosses a trust boundary, requiring secure internet protocols.
   • The cloud servers and IoT applications operate within the same infrastructure, maintaining a shared trust boundary.
   • Interactions between IoT applications and end users introduce a trust boundary, where authentication and secure access are essential.
   • Data exchanges between IoT applications and business systems form another trust boundary, ensuring secure and controlled data integration. 

Figure 1: IoT door lock system with the highlighted trust boundary. 

Output

The output of the process is the system and data flow diagrams. The diagram gives you an overview of your system and how it interacts with external entities. The identified trust boundaries reveal the extent of control you have (or do not have) over these elements, thus highlighting potential attack surfaces. 

Expert advice

It is beneficial to involve both individuals with business understanding and technical insight in the system modelling step as it helps build a shared understanding of the system. 

Next steps

After drawing the system diagram, the next step is to identify the assets that are important to the organisation. This is described in more detail in Asset identification. 

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

CyPro