The medical device as a stand-alone product is a waning concept.

The desire to make use of the information collected in a medical device in other health systems, coupled with recent advancements in networks and interconnectivity has resulted in more devices being connected to the Internet. As a consequence, they have become more vulnerable to hackers.

A 2015 KPMG survey found that 81 percent of health care organizations had their data compromised within the previous two years.

FBI reports (FBI Cyber Division PIN (Private Industry Notification) #140408-010) that due to the transition of paper to electronic health records, lax cybersecurity standards and higher financial payout for medical records in the black market, the "cyber actors will likely increase cyber intrusions against health care systems". 

During 2016, several ransom-attacks were launched against health institutions in the United States with wide-ranging consequences. 

FDA has shown heightened interest in cybersecurity issues and released three guidelines during the last two years. Medical Device manufacturers are likely to focus more on cybersecurity risk management activities in the near future and assign additional resources accordingly.

One integral part of the cybersecurity risk management process constitutes the risk assessment.

Performing risk assessments is a core activity in the medical device industry and many of the available techniques are well-known and well-used by industry professionals. Having long and thorough experience of risk management might lead the same professionals to believe that cybersecurity issues can be harnessed by the tools already at hand.

There are, however, key aspects where cybersecurity risks differ from traditional medical device risks.

Risk identification and the building blocks of a cybersecurity risk

The fundamental challenge during risk identification is to ensure that all relevant risks have been identified.

Verifying that this criterion has been fulfilled is often difficult and therefore structural help and practical advice is very welcome.

Due to the wide variety of possible medical device types, ISO 14971, the standard for medical device risk management, understandably has a hard time defining concrete identification techniques that are relevant enough to provide value for every kind of medical device. 

IT risk management, operating in a narrower technical scope, provides a host of techniques, tailored to this domain. Many of these techniques are based around the asset-vulnerability-threat model. 

These components can be described as followed.  

• Assets are the entities a cyber-intruder attempts to access and control. An asset has a value to the patient and therefore also to an intruder. In a safety-related context, we can exemplify assets as device configurations, health data, medical device functions, or battery power.
• Vulnerabilities represent weaknesses in the medical device that, when exploited, can give an intruder access to an asset. Software bugs, application design flaws, and insufficient input validation are examples of software vulnerabilities. But vulnerabilities can also be found in hardware, business processes, organizational structures, and interpersonal communication.
• A threat is defined as an event with the potential to an adverse impact on an asset. The threat is executed by a threat agent (i.e. an intruder) exploiting a vulnerability in order to access an asset.

A combination of these building blocks describes a cybersecurity risk. 

As a starting point, the manufacturer should be able to enumerate assets for the given device. By analyzing how these assets can be targeted, e.g. by performing a “Threat modeling analysis”, using a data flow analysis of the application, identifying "data-at-rest" (data storage) and "data-in-motion" (data transfer) will further help the manufacturer to identify vulnerabilities and threats, particular to the medical device.

Bottom-line: Identifying assets, threats, and vulnerabilities will support the manufacturer when enumerating potential cybersecurity risks. The identified items should be listed in the risk management documentation.

What is the probability of a cyber attack?

The Medical Device industry takes its risk assessment cues from ISO 14971, which defines risk as the combination of the probability of the occurrence of harm and the severity of that harm. 

The computer security industry, on the other hand, has used several kinds of assessment methods to estimate the "riskiness" of cybersecurity risks. None of them rely solely on the probability and severity of an event. Instead, these techniques estimate and/or quantify aspects of the assets, threats, and vulnerabilities that in combination say something about the computer security risk. 

So how can the medical device risk assessment methods concerned with the safety of patients be connected with techniques whose primary concern is information security?

In the AAMI paper "TIR 57 - Principles for medical device security - Risk Management", the authors address this discrepancy and attempt to transpose the cybersecurity line of thinking into the domain of ISO 14971. 

It is easy to see how the "potential adverse effect" can be regarded as analogue to the “Harm” in ISO 14971 and be quantified with a corresponding severity.

The probability factor in ISO 14971 does not have a direct equivalent in the cybersecurity risk domain. A composite factor called "exploitability" combining characteristics of the vulnerability, the threat agent, and the medical device itself is mentioned in the FDA guidelines. This factor intends to indicate the amount of work involved in order to invoke a successful attack.

The AAMI TIR57 group suggests a two-pronged approach to establish something similar, combining two likelihood factors.

The first factor, the “Threat Likelihood”, defines the likelihood of the threat agent having the motivation, skills, and resources to exploit a given vulnerability.

The second factor estimates the likelihood of harm being the effect of an exploited vulnerability.  These two factors in combination make out the probability of the cybersecurity risk.

Note that this approach is similar to the P1 (probability of the hazardous situation occurring) / P2 (probability of the hazardous situation causing harm) frequently used in the medical device community.

Information security theory recognizes that aspects and characteristics of the threat agent, the vulnerability, and the device itself drive these factors.

Bottom-line: caution shall be taken when estimating probability/likelihood/exploitability for cybersecurity risks. The manufacturer's Risk Management SOP shall address this concern accordingly and be adapted if necessary.

The drivers of cybersecurity risks

During classic medical device risk assessments, the identified causes leading to hazardous situations and potentially to harms are in most cases accidental. Although malicious use should be considered, this area often receives considerably less attention than harms caused by accidental events. 

For cybersecurity risks, the opposite is true. Here, a significant factor in the causal chain constitutes the intentional behavior of a threat agent causing harm by exploiting a vulnerability.

Whereas the software flaw might have been created accidentally, exploiting it is an intentional act.

A malicious agent may come in many shapes and forms, such as a criminal organization, a competitor, or disgruntled employees. Each of these has its own motivation, skill set, and reach when it comes to detecting and exploiting vulnerabilities, which affects the likelihood of a vulnerability being exploited as we have seen above.

Therefore, not only needs the focus to be shifted from accidentally caused risks to intentionally caused risks. The manufacturer benefits from analyzing the characteristics of the malicious intruder in order to do a proper risk assessment.

Bottom line: Manufacturers will need to shift perspective from accidentally caused risks to explicit maliciously caused risks during the identification and classification of the risk assessment.

The poisoned SOUP

Just like in the rest of the software industry, medical device companies use third-party libraries to increase productivity when developing medical devices.

These third-party libraries (or frameworks or applications), sometimes referred to as "SOUP" components (Software of Unknown Provenance) are of course also subject to cybersecurity scrutiny.

It is debatable if third-party components, and in particular open source components, are inherently more unsafe than proprietary produced applications (there are several arguments against such claims).

Regardless of this claim, it can be safely assumed that many of these libraries were not developed with a medical device cybersecurity context in mind. The security firm “Contrast Security” reports that 26% of downloaded SOUP:s contained known vulnerabilities and were still applied.

It shall be noted that SOUP:s themselves often rely on and integrate third-party software, which increases the scope of the problem accordingly.

The medical device manufacturer is responsible for any vulnerabilities caused by SOUP:s in his device and must therefore analyses his SOUP:s accordingly.

This shall include a systematic inventory of SOUP:s, actively collecting information on current vulnerabilities in SOUP:s as well as applying timely updates of the SOUP:s when available.

Bottom-line: The manufacturer must have a clear plan for how to handle potential cybersecurity risks in SOUP:s. 

Skills required to assess cybersecurity risks

Cybersecurity vulnerabilities are largely made up of software flaws. Understanding the technical details of how such vulnerabilities come into being, the technical influence they have, and how they can be mitigated requires precise software knowledge. Including software developers in the assessment group is, therefore, a highly recommended measure.

It is a misconception that all software professionals are software security professionals. The majority of today’s information security problems can be traced to flaws in code. Many software developers lack basic training and understanding of cybersecurity. 

As already mentioned, the security scope for an interconnected medical device is much larger than the device itself. The network infrastructure in which connected medical devices operate is often outside the control of the medical device manufacturer but still has a great impact on the overall risk exposure and needs to be included in the risk assessment.

It is likewise a misconception that cybersecurity is a strictly technical field. Cybersecurity vulnerabilities are not exclusively found in hardware and software but also in business processes, organizational structures, human behavior, and the environment in which the device operates. A thorough understanding of where, how, and by whom the medical device will be operated is therefore important input for the risk assessment.

Last but not least, the clinical experts are required for estimating the potential harm of compromised availability, confidentiality, and integrity of the associated data.

All these competencies are required in order to perform a comprehensive cybersecurity risk assessment and it is clear that it stretches beyond being an internal R&D activity.

The risk assessment benefits from involving stakeholders beyond the immediate software development team. If specific cybersecurity expertise is lacking in the organization, the manufacturer should consider employing or train their own experts or outsource these functions to a competent partner.

Bottom-line: the knowledge required to perform a medical device cybersecurity risk assessment is both broader and deeper than what is often immediately available in many medical device companies. 

Conclusion

The medical device industry has extensive experience with risk management and risk assessment techniques.

The cybersecurity dimension of medical device development is an additional aspect where risk assessments can enhance safety.

However, traditional medical device risk assessment techniques need adaptation in order to successfully be applied to cybersecurity risks.

Cybersecurity risks consist of other aspects and other drivers than "classic" medical device risks and are best mitigated by recognizing these differences.

Cybersecurity issues resulted in 465 000 St Jude pacemakers being subjected to an FDA recalldue to fears of exploiting existing cybersecurity vulnerabilities in the device. A security hole exposes the device to hacking risks, potentially resulting in running the batteries down or even alter the patient’s heartbeat.

Although the risk is extremely low, the cost for St Jude / Abbott is significant. For a smaller firm, these ramifications can be detrimental. The long lifetime of medical devices and an ever-evolving cybersecurity arena makes devices vulnerable to cyber risks. Handling them effectively will be a significant challenge for the industry in the years to come.

We are addressing Cybersecurity Issues in the Supply Chain during a Keynote at the Swiss Medtech Expo in Luzern, 19-20 September.

Join us for this key note or come and meet us at the Expo at Booth B2045, Halle 02.

Finally! State-of-the-art Medical Device IT Security Requirements! And they are free! And you can download them!

For those of us who (in vain) have poured over IT Security standards and guidelines of variable quality in order to distillate useful requirements: look no further! A state-of-the-art, useable Medical Device IT Security guideline is finally here!

The Johner Institute has in collaboration with TÜV SÜD, TÜV Nord and Dr. Heidenreich (Siemens) compiled an excellent set of Medical Device Cyber Security Process and Product requirements and made it available to the industry for free.

Roughly 150 IT Security requirements are available in the Guideline covering both process requirements as well as product requirements, including the level of expertise needed to implement them, are available in the following structure:

Process requirements

Requirements for the development process

• Intended purpose and stakeholder requirements
• System and software requirements
• System and software architecture
• Implementation and development of the software
• Evaluation of software units
• System and software tests
• Product release

Requirements for the post-development phase

• Production, distribution, installation
• Market surveillance
• Incident response plan

Product requirements

• Preliminary remarks and general requirements
• System requirements
• System and software architecture
• Support materials

This IT Security Guideline is directed to Medical Device Manufacturers as well as Auditors, Reviewers, and Hospital Management.

Dr. Johner and his collaborators have in this guideline managed to deliver concrete, best-practice guidelines, something that most other standards and regulations certainly tend to lacks.

The entire guideline is available in the GitHub-Repository „IT Security Guideline“ (https://github.com/johner-institut/it-security-guideline/) and is a recommended read for everyone concerned with Medical Device cybersecurity. You can also download Excel files with the requirements from the Johner Institute website.

We have made the Product IT Security Requirements available as a downloadable extension for Aligned Elements. It is recommended to use them in conjunction with the material in the mentioned GitHub-repository, which contains valuable additional information and footnotes that explain the rationale and context for some of the requirements.

Performing Medical Device Cybersecurity Risk Assessments is something we Medical Device Manufacturers must get used to. And the sooner the better, During 2016 and 2017 a mounting number of health associated cybersecurity incidents have been reported. Cybersecurity breaches may well become THE main safety concern in our industry within the next few years. Increased regulation on this matter is to be expected.

FDA has already published guidelines on its view on how medical device manufacturers ought to address cybersecurity in Medical Devices. The guidance outlines the documentation FDA expects to see in the premarket submissions as well as what is expected to be conducted for SOUPs and during postmarket activities.

At the core of this documentation lies the Cybersecurity Risk assessment. As already discussed, this type of risk assessment is slightly different to the typical Design Risk Assessment conducted during development.

To address this task, which many manufacturers will have to perform, we have developed a risk assessment template set specifically for documenting Cybersecurity risks and mitigations.

This template package is free to download and use for all Aligned Elements customers.

Are you interested in how the Cybersecurity Risk Assessment can be conducted and integrated with the rest of your Design Controls?

Diese E-Mail-Adresse ist vor Spambots geschützt! Zur Anzeige muss JavaScript eingeschaltet sein. for a free demonstration!

The Aligned Elements Cybersecurity Risk Assessment package contains:

• Risk assessment templates based on AAMI TIR 32, modeling Assets, Threats, Vulnerabilities and Risk Controls as Measures
• More than 30 Best Practice Cybersecurity Risk Mitigations ready to use

If you are looking for a Cybersecurity Risk Assessment Word Template, you can download an example here:

Cyber Security Risk Assessment Word Template

Within the last 24 months, mobile health technologies (eHealth apps) have radically changed the way we think about health and medical devices. The combination of smart apps and wearable sensors has brought monitoring and diagnostic power into the hands of the patient, increasing value and utility, often to a very competitive price. There is a surge for patient-centric offerings across the industry, truly leveraged by the new mobile health technologies. 

Ava Women is one of the companies that has moved quickly in the right direction and with the product “Ava”,an advanced fertility tracking bracelet, they assist women and couples in narrowing down the right timing of a successful conception.

We were lucky to get a word with Mr. Philip Tholen, Co-founder and VP of Operations of Ava Women, and took the chance to ask some questions about the opportunities and challenges that face a "wearables"-company.

Mr. Tholen, we have seen a host of consumer electronics companies, including Apple, Microsoft, and Google, with little or no experience in medical device development, trying to penetrate the market with wearable technologies, banking on their expertise in consumer products. 

There are also more traditional companies such as Medtronic, with substantial experience in medical device development that are now jumping the bandwagon, attempting to entering this new playing field.

Looking at the two extreme ends of this spectrum, where would you say the Ava story fits in?

I would say we are positioned right between these two extremes. On one hand, we have a Class I regulated medical device with all its pros and cons. This demands for compliance with GMP, FDA Class I, taking IEC 62304 into consideration, etc. On the other hand, we focus on selling directly to the end-user. In that sense, we have to market our medical device as if it was a consumer product. Striking this balance is not always easy.

With numerous players grabbing for their share, I assume that speed is of the essence in the mobile health market and time-to-market is critical. What measures has Ava taken to make sure that the development proceeds as fast as possible?

Exactly. Our market operates as fast-paced and as short-cycled as a classical consumer market. But in the background, we still have to assure compliance and organize our company in the classical medical device way. Guess how long the lights are on in the Ava-atelier each night!

In order to be fast, we massively parallelized all process steps right from the start. For example, we started hardware development even before we had the clinical study results which delivered the data we need and which confirmed that the sensor concept we chose works. We made so many educated guesses! But luckily, it always worked out and we never had to go back to the drawing board due to inaccurate assumptions.

Furthermore, we purposely selected “off-the-shelf” hardware technologies and components. We neither had our suppliers develop or modify components specifically for our purpose nor did we trust in suppliers’ statements such as “we will have this new product ready when you are going into production”. Only what’s already been commercially available in the mass market made it to our product concept shortlist. We could effectively eliminate the risk of supply-related delays using this approach.

Developing a working medical device is a formidable task per se. Doing it in the strictly regulated environment of medical devices is usually not making it easier. How has Ava, as a start-up company, managed to tackle the regulatory challenges of the medical device market?

Since the beginning we kept an eye on regulatory aspects of product development: for example, we have always made sure that candidates have experience in this field when we selected key team members. Furthermore, during the hardware supplier selection process we only considered ISO 13485 certified companies. On top of that, we have hired a highly experienced professional who is busy refining our QMS and accelerate us through an ISO 13485 certification in due time before market launch. All of these steps might be expensive and seem much work for a startup, but they are part of our strategy to become a cutting-edge digital health company providing state-of-the-art technologies for the end-user as well as for medical professionals.

There has been much debate lately about cybersecurity and data integrity when it comes to mobile health applications. Even FDA has concerns about how patient data is stored, transferred, and accessed. How has Ava addressed these questions?

We are taking the FDA guidance on cybersecurity very seriously. Confidentiality and data integrity is paramount for us, as is the trust our customers have in our product. All data in our application is stored, handle, and transmitted with utmost vigilance. Our security concept is being challenged and improved periodically, and it will also be audited by independent third parties. However, making sure that security measures do not impair the usability of our device shall not be neglected. Luckily, I am confident to say that we have the right team in place to cope with these challenges.

Finally, based on your experience with Ava, do you have any advice to other start-ups currently thinking about embarking on a similar journey?

Do not underestimate the commercialization process of a medical device! Having a working prototype is a good start, but there are many other pieces that have to be put in place before you can place the product on the market. Having the right team and the right partners will certainly make that part of the journey less rough.

AVA Women uses Aligned Elements to manage their medical device development documentation. 

Learn more about how Aligned Elements can help with achieving regulatory compliance for your app

Request a live demo and let us show you how Aligned Elements can manage your documentation for your app

As a medical device manufacturer, you are probably well aware of the increasing focus on cyber security. When developing your device, you are responsible for ensuring that it is safe to use from a cyber security perspective.
I think it is safe to say that the attention placed on cyber security aspects by autors and national authorities will only increase in the coming years.

FDA has issues a number of guidelines on how to implement and apply cybersecurity both on a process and product level. It is up to you as a medical device manufacturer to provide adequate cyber resilience in your products as well as the documentation required to prove it.

Aligned Elements users have for a long time been able to leverage Cyber Security extensions in their Aligned Elements configurations such as the Medical Device Cybersecurity Risk Assessment Templates and the Johner Institute Medical Device IT Security Product Requirements.

We are now happy to include the new OWASP Top 10 Checklist to our library of Cyber Security Extensions.

What is it?

OWASP stands for “Open Web Application Security Project”. It is a non-profit entity with international recognition and focuses on collaboration to strengthen software security around the globe.

OWASP publishes the OWASP Top 10 list, which provides rankings of, as well as a remediation guidance for, the top 10 most critical web application security risks.

It uses the extensive knowledge and experience of the OWASP’s open community contributors, and is based on a consensus among security experts from around the world.
The OWASP Top 10 risks are ranked according to the frequency of discovered security defects, the severity of the uncovered vulnerabilities, and the magnitude of their potential impacts.

You can now easily assess and automatically document how well your medical device application stands up against the OWASP Top 10 by applying the Aligned Elements OWASP Top 10 Regulatory Assistant in your Aligned Elements projects.

How does it work?

This Assistant takes the shape of a Checklist where you assess your own medical device against the OWASP Top 10 security risks.

You start out by assessing whether the risk is applicable to your device at all, and if not, provide a qulified answer why this is not the case (the auditors rewards such qualifications).

If the risk is applicable, you are required to refer to the Aligned Elements Design Control Items that addresses the risk by selecting them in the UI.
You can compare your risk reduction controls against known best-practice remidiations mentioned in the OWASP Top 10 list.

When the checklist is completed, a Regulatory Assistance item is generated, containing all steps and your provided answers. This information remains stored in Aligned Elements for compliance purposes.

The OWASP Top 10 Regulatory Assistant Checklist is free to all Aligned Elements customers and can be applied to any Aligned Elements Web Server installation.

Note! The OWASP Top 10 Regulatory Assistant Checklist only works in Aligned Elements.