Cybersecurity Part 2: Navigating the hilarious chaos of getting started

I can still remember my first contact with the topic of cybersecurity. Back then, I took part in an external audit for a customer. Before the break, the auditor said that we would next devote ourselves to the topic of safety and security. Members of top management then approached the quality managers and risk managers and asked, do we have anything about security. The answer was no.

Too much information…

Good for me as a consultant because I was allowed to do additional tasks for the customer, bad for the company. The topic of cybersecurity has been addressed from time to time in the standards, but no useful explanations have been provided as to what needs to be done. The MDR also mentions the topic of security in six places, talking about security controls, security measures, security patches and security verification and validation. The promising IEC 810001-5-1 was only announced at the time, but unfortunately it would not have been of much help in the situation, as this standard does not provide any practical instructions either.

As a consultant who is also familiar with American regulations and who has already worked on one or two submissions and has seen the extent of the cybersecurity documentation, the next step was to search the FDA guidances. And I found what I was looking for, but the amount of information was overwhelming.

Not quite what I was looking for

Most of the information I found was dealing with the risk assessment of cyber security threats, such as NIST SP 300 tables or the common vulnerability scoring system (CVSS). The two assessment methods were discussed in the first blog of this cybersecurity series, “The threat of threat analysis”. The information was valuable but at this point of time there were no threats identified, so there was nothing to evaluate. The aim of the project was still to find the entry point and to provide people who are not necessarily familiar with cybersecurity with tools and methods to identify the threats.

Sometimes the simple solutions are the best

The solution to the problem was then found in the FDA Playbook for threat modelling. The playbook emphasis the need to start at a high level, such as a block diagram of a system and using data flow diagrams (DFDs). The idea behind the DFD is to identify the entities involved in the functioning of the medical device, to determine the relationship between the entities and to establish trust boundaries.

The icons for DFDs are defined and self- explaining, and system architects are usually familiar with the icons as they use them in their system architectures.

Table 1: Icons used in DFDs as described in the FDA playbook for threat modelling

The first task of the team is now to set up a block diagram of the medical device and brainstorm what entities are available and how they interact with each other. The team defines what data is sent between the entities.

Take a closer look at cybersecurity risk assessment strategies in our  Medical Device Cybersecurity course. Schedule your next training with us or send a direct inquiry at

Erfahre mehr

The next step is to use the block diagram and model the DFD. More information is added to the individual components and other entities that may be relevant to the threat modelling process. Other entities might include external entities that are not under the manufacturers control such as mobile devices from clinicians.

Trust boundaries are conceptual lines drawn by the threat modelling team to illustrate assumptions about the interactions between various entities. These boundaries play a crucial role in subsequent stages of the threat modelling process by pinpointing areas necessitating deeper scrutiny. Moreover, they serve as a tool to encapsulate the rationale behind the threat modelling team’s deliberations, facilitating effective communication with external reviewers.


Let’s look at an example. In this setting there is a dialysis machine that measures certain parameters of the patient with a sensor and transmits the data to a mobile device of a physician. There are several USB ports for the maintenance personnel available. The app where the patient data is displayed is also manufactured by the manufacturer of the dialysis machine. The mobile device does not only contain the dialysis app but also apps from other medical devices from different manufacturers and as nightshifts might sometimes be boring, some gaming apps. The dialysis station is equipped with some computers to monitor the hole setting. All data is then sent to the hospital infrastructure and stored accordingly. Figure 1 shows an example of an DFD for the previously described system.

Figure 1: Example for an DFD

As the manufacturer developed the dialysis machine and the app, trust boundaries can be set because the manufacturers can control these parts of the system. Also the hospital infrastructure was evaluated as to be trusted.  What the manufacturer cannot control and therefore cannot be trusted is the mobile device of the physician. There are several unknown apps installed and in case of gaming apps also from untrusted sources. Also, the computer on the dialysis station might cause potential threats.

The great advantage with this method is that a team can easily get a first idea of potential threats without needing a detailed technical understanding of the system.


Engineers are often said to be lazy. The better term would be efficient. Therefore, many readers will now think whether they always must deduce the threats themselves or whether there is one or two tools that support this task as a Bluetooth threat might always be the same for different types of devices. The good news is that other engineers have also thought and not only thought but also developed tools and made them commercially available to support threat modelling. One open-source tool is OWASP threat dragon providing the possibility to draw DFDs and supporting threat analysis with suggestions and examples. A commercially available tool is IriusRisk also providing the possibility to draw DFDs and providing databases to support threat modelling with common known threats. IriusRisk can be integrated in commonly used requirement management systems such as Jira and others, giving the team the possibility to create tickets and synchronizing the ticket processing with the threat model. 

In our next blog of the series we shall look at cybersecurity testing activities such as penetration testing and fuzz testing.

By Verena Wieser, Medical Device Consultant

If you would like to join one of our cybersecurity training courses, take a look at our training courses for safety-relevant standards or if you are looking for consultancy support, please do not hesitate to contact us at



Wir freuen uns auf Ihre Kontaktaufnahme.

    Datenschutz­bestimmungen anzeigen