Cybersecurity and the Medical Device Product Development Lifecycle Richard W. JONES a,1 and Konstantinos KATZIS.b School of Engineering, University of Warwick, U.K. b Department of Computer Science and Engineering, European University Cyprus. a
Protecting connected medical devices from evolving cyber related threats, requires a continuous lifecycle approach whereby cybersecurity is integrated within the product development lifecycle and both complements and re-enforces the safety risk management processes therein. This contribution reviews the guidance relating to medical device cybersecurity within the product development lifecycle. Abstract.
Keywords. Cybersecurity, Medical devices, Life-cycle, Risk Management.
1. Introduction The first decade of the 21st century has brought about significant changes in the medical device landscape. The ever-increasing connectivity of software-controlled medical devices has created much concern about cyber- related vulnerabilities [1] which has only heightened with the recent ransomware attack on the U.K.’s National Health Service (NHS) [2]. Cybersecurity concerns are especially prevalent with regard to connected implantable medical devices (IMDs), where the associated safety risks if a cyber-attack is successful are extremely high. The range of cyber-attacks that medical device companies and healthcare organizations are trying to defend against, include; malicious software introduced into the device or system, device operation disrupted by blocking the flow of operation, false information sent to operators to initiate inappropriate actions by medical staff and unauthorized changes made to embedded software or unauthorized commands issued to devices [3]. Additionally the economics relating to medical device cybersecurity normally involves a complex system of payments between the multiple stakeholders— including manufacturers, providers, and patients The U.S. Food and Drug Administration (FDA) released guidance for the management of cybersecurity in medical devices [4] in October 2014. It recommends that manufacturers “consider cybersecurity risks as part of the design and development of a medical device, and submit documentation about the risks identified and controls in place to mitigate those risks.” Thus the FDA is indicating that manufacturers consider the possibility throughout the total product lifecycle of a device, therefore refocusing medical device development to include security, in addition to safety, as a key element. Specifically the guidance recommends the following: Identification of assets, threats, and vulnerabilities; Assessment of the impact of threats and vulnerabilities on device functionality and end users/patients; Assessment of the likelihood of a threat and of a vulnerability being exploited; Determination of risk levels and suitable mitigation strategies; and
1:
Corresponding author:
[email protected]
Assessment of residual risk and risk acceptance criteria. The guidance also identifies "core functions" of cybersecurity activities from the National Institute of Standards and Technology (NIST) cybersecurity framework [3]. A 2016 US security framework adoption study reported that 70% of the surveyed organizations see the NIST Cybersecurity Framework as best practice for computer security. 2.0 The Medical Device Product Development Lifecycle There are a number of different product development lifecycles used to design and develop medical devices with development usually containing the following steps; specification, design, development, testing manufacturing and subsequent to regulatory approval, product launch and post-market monitoring. Figure 1 shows parts of the FDA’s product development pathway particular to medical devices where the ‘invention + prototyping’, ‘pre-clinical’ and ‘post-market monitoring’ phases encompass most of the recognised product development activities [5].
Figure 1. The medical device development pathway, adapted from [5]. The interaction between the regulatory process with the pathway, which accommodates the iterative and cyclical nature of medical device design and development, is not indicated.
It is possible for medical device manufacturers to apply a variety of security development lifecycles. For example the British Standards Institution (BSI) recommends that manufacturers consider following the good practice outlined in security standards developed for industrial automation and control system security; IEC 62443-4-1:Product Development Requirements and IEC 62443-4-2: Technical Security Requirements [6]. Basic safety standards for functional safety, utilized across other domains, now address cybersecurity throughout system lifecycles and recommend approaches to secure products, systems and networks. They also reference IEC 62443. The majority of research into security and privacy has centered on threats to the telemetry interface [1] though security experts have begun advocating that a more holistic approach to securing increasingly complex and connected medical devices be taken [7]. Despite the challenges, the importance of ongoing security evaluation throughout the life-cycle of the medical device is now accepted. Figure 2 illustrates dedicated security activities superimposed over the software design lifecycle [8]. Comprehensive threat assessment, carried out after the requirements stage, is the most fundamentally important activity. The use of static analysis tools, as part of the software security lifecycle, are highly recommended by software safety standards because they enforce strict coding standards, such as MISRA-C, to prevent defects as well as finding any defects that do occur before unit testing. Static analysis also provides automated documentation to support testing, coding standard and quality/robustness evidence [8].
1:
Corresponding author:
[email protected]
Figure 2. Security standards superimposed over the software design lifecycle, adapted from [8].
3.0 Cybersecurity Risk Management FDA’s Postmarket Guidance [9] recommends manufacturers implement a process for assessing cybersecurity risk to the device’s clinical performance by considering: Exploitability of the cybersecurity vulnerability; and Severity of the health impact to patients if the vulnerability were to be exploited. The FDA does recommend that a cybersecurity vulnerability assessment tool, such as the Common Vulnerability Scoring System, be used for assessing how exploitable a particular vulnerability is. However, estimating the probability of a cyber-attack is problematic given the absence of data on the probability of the occurrence of harm. This difficulty also applies to software failure and other situations such as sabotage or tampering with a medical device. The approach recommended in EN ISO 14971 [10] is to use either the worst possible case outcome or set a default value for the probability as one, indicating that worst-case scenarios drive the cyber-protection level of the device. For assessing the severity impact to health, the FDA suggests the approach based on qualitative severity levels as described in EN ISO 14971. Cybersecurity priorities do differ depending upon how the medical device is deployed. Confidentiality is a priority for hospital systems, preventing data breaches, or ransomware (which impacts the availability of systems if made unusable by encryption, such as in the NHS attack [2]). Protection of the patient is a priority where they are exposed to medical devices (including implantable devices) as part of their care. In [11] the authors’ discussed specific cybersecurity mitigations applied to IMD’s, such as authentication strategies, and their possible impact on the safety of the patient and the need for the designers to take this in account. The Association for the Advancement of Medical Instrumentation (AAMI) appreciate that medical device security can become a patient safety issue, such as in IMD authentication, and should be treated as such during risk management related activities within the product development lifecycle [11]. The AAMI indicate that the controls or countermeasures employed for security mitigation be assessed for their impact on safety functionality in order that new hazards are not introduced. To provide some degree of transparency with regard to the relationship between product development activities and cybersecurity, figure 3 illustrates product
1:
Corresponding author:
[email protected]
development activities, represented here as a V-model, and the corresponding software security lifecycle activities, indicated in red [13].
Figure 3. V-model based Product Development Lifecycle with complementary Security Risk related software orientated, actions indicated. Adapted from [13].
4.0 Discussion Much of the medical devices cybersecurity guidance is recent and will evolve and develop as (a) the nature of cyber-attacks evolve and (b) the emergent properties, that is ‘vulnerabilities’, of existing and new medical devices, become known. It is now recognized among the different stakeholders that establishing cybersecurity has to be a collaborative effort throughout the product development lifecycle. Previously medical device risk management focused on functional safety, safety-related risk (to the exclusion of cybersecurity) or the protection of data. Multiple approaches are now actively addressing the lifecycle risks and potential harm from cybersecurity incidents. References [1] M. Rushanan, SoK: Security and privacy in implantable medical devices and body area networks. Proceedings of the 2014 IEEE Symposium on Security and Privacy. (2014), 524–539. [2] www.theguardian.com/society/2017/may/12/hospitals-across-england-hit-by-large-scale-cyber-attack [3] National Institute of Standards and Technology (NIST). Framework for Improving Critical Infrastructure Cybersecurity (Ver. 1.0) Feb. 12, 2014; http://www.nist.gov/cyberframework/upload/ cybersecurityframework-021214-final.pdf (accessed April 26th, 2017). [4] www.fda.gov/downloads/medicaldevices/deviceregulationandguidance/guidancedocuments/ucm356190. pdf (accessed April 26th, 2017) [5] www.fda.gov/aboutfda/centersoffices/office ofmedicalproductsandtobacco/cdrhinnovation/ucm242067.htm (accessed April 30th, 2017). [6] www.bsigroup.com/LocalFiles/ENAU/ISO%2013485%20Medical%20Devices/Whitepapers/White_Pape r___Cybersecurity_of_medical_devices.pdf (accessed April 26th, 2017). [7] Z Zhang, M. et al. Towards trustworthy medical devices and body area networks. Proc. of the 50th Annual Design Automation Conference. ACM, (2013), 1-6. [8] blogs.grammatech.com/designing-secuirty-into-medical-device-software (accessed April 25th, 2017). [9] www.fda.gov/downloads/medicaldevices/deviceregulationandguidance/guidancedocuments/ucm482022. pdf (accessed April 26th, 2017). [10] EN ISO 14971: 2012: Medical Devices – Application of Risk Management to Medical Devices. [11] K. Katzis, R.W. Jones, G. Despotou, The Challenges of Balancing Security and Safety in Implantable Medical Devices, Studies in Health Technology and Informatics. 226 (2016) 25-28. [12] TIR57: Principles for medical device security – Risk management, AAMI, (2016). [13] www.nccgroup.trust/uk/about-us/newsroom-and-events/blogs/2014/october/asdl-the-automotivesecure-development-lifecycle/ (accessed April 27th, 2017).
1:
Corresponding author:
[email protected]
