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 info@lorit-consultancy.com.
Learn more
