Understanding Cybersecurity In Medical Devices And Applications
Understanding Cybersecurity in Medical Devices and Applications1. IntroductionOne of the major pillars of the current Industry 4.0 is Automation. Indeed, technology isintervening in almost every domain to “automate” the workforce and make human life easier andbetter. In the present age, machines are getting integrated with the Internet of Things, CloudComputing, and Artificial Intelligence with the data flow being transferred and processed via theInternet. These changes indeed catalyze the overall productivity, but also expose data to the publicdomains. 1In cases of continuous data transfers and exposition, Cybersecurity becomes a pivotalelement where it not only protects the data but also proactively provides mechanisms to defendagainst malicious attacks and malware. In the case of medical devices that include sensitivemedical data flows and software-controlled hardware devices like heart implants or ContinuousGlucose Monitoring (CGM) devices, Cybersecurity becomes an important factor for contributingtowards system safety and quality. To ensure that medical devices, software, and applications (webor mobile-based) are safe and effective before releasing them in the market, FDA mandatesCybersecurity measures be implemented to protect against cyber-attacks. Also, the FDA mandatesthat medical device manufacturers be compliant with the industry-accepted Cybersecurityprotocols. 2In this paper, we begin by specifying the vulnerabilities identified in the medical systems.The vulnerabilities include the potential data access points which later might be identified bypatients, clinicians, device manufacturers, or cybersecurity/software engineers as the points of databreaches. The later part of the paper discusses the recent attacks in the field of healthcare andmedical services. In the next key section of the paper, we provide the guidance methodologies forpre and post device submission which includes the steps taken by the device manufacturers andsoftware engineers if they identify a threat in the system after the product is live, or if the systemhas suffered a cyber-attack. The same section also includes the cybersecurity standards acceptedby the FDA. Before concluding the paper, we outline strategies that may be used to mitigateCybersecurity risks which also include the roles and responsibilities of device manufacturers,patients, health care personnel, software developers, and the FDA to ensure data security andpatient safety.2. Vulnerabilities in Medical Devices & Software ApplicationsVulnerabilities can be defined as the data access points through which computer malware,worms, or viruses can be injected. These malicious elements are small, scripted code snippetswhich function to disrupt the normal functioning of a computing system, such as filling the serverwith continuous iterative request calls, which overloads the server outside its handling capacityand eventually crashes the machine. In some cases, these viruses may also function to block certainfunctionalities like permanently changing device and system access passwords.It is vital to understand the access points in medical devices and applications sinceproactively securing and isolating them will prevent the very first step that is showcasing the data.One of the platforms currently all applications and devices are migrating to is the Internet of Things(IoT). In IoT, devices speak to one another via data transfer and automate the software processwith help of sensors and communication tools like Bluetooth, Radio Frequency (RF) Tools, Zigbee
[which is a communication tool for devices placed in proximity], LAN based networks, and in theend, the Internet.Bluetooth has revolutionized the way devices communicate and is actively used as a datatransfer tool in almost every computing device. But it is also one of the devices which makes theentire system most vulnerable. If the latest Bluetooth firmware and updates are not installed, itmakes devices highly vulnerable as hackers can access these tools using a technique called“Bluebugging”. If hackers access a Bluetooth-enabled device using Bluebugging, they havecomplete control of the device. Such devices include examples like Bluetooth-based printers,cameras, vehicles, and remotely controlled machines. 3Another major vulnerability is using information systems locally with outdatedtechnologies. Examples of information systems include Hospital Management Systems and datarepositories such as Blood Banks and Organ Preservation Repositories. If attackers get access toone of these systems, they can relay attacks to other connected information systems. These attacksmay be induced by clicking malicious email links or keeping the system active without securedsessions. One of the similar reasons for vulnerability is using old pieces of hardware, software,middleware, and firmware. 4 New or current devices may include frameworks to secure themselvesagainst the latest viruses, but with old systems installed, they may not even possess the mechanismto understand new malware and viruses, which results in the system getting attacked and hamperedin terms of functionality.3. Real Cases of Cyberattacks & FDA Concerns in Medical Devices and ApplicationsOn June 18, 2018, the Fetal Diagnostic Institute of the Pacific was hit by a ransomwareattack which breached the data of 40,800 patients. An employee of Philadelphia-based Blue Crosshospital exposed online the data of 16,762 patients by uploading the patient data file to a publicwebsite. In Orlando, at the Orlando Orthopedic Center, a third-party software upgrade resulted inexposing data of 19,101 patient records for two months. A Missouri-based Blue Springs FamilyCare stated that they suffered a data breach of 44,979 patient records after hackers peppered theprovider with a variety of malware, including ransomware.6 In 2020, Netwalker, a ransomwareoperator that threatens to publish data online if ransoms aren't paid, hacked Springfield, Pa.-basedCrozer-Keystone Health System and tried to auction it’s data online. Houston based Harris HealthSystem reported the loss of 2,298 patient records. In June 2020, the Florida orthopedic group washit with a 99M lawsuit due to personal patient data exposure because of a malware attack. 5 Themost recent incident recorded was by the University of California San Francisco stating they paid 1.14 million to hackers after a June 1, 2020 ransomware attack on servers blocked access to theirmedical school's computer systems. 6In 2013, the FDA started observing and reporting cybersecurity concerns in medicaldevices and applications. In the 2020 safety communication section, FDA posted the case of the“SweynTooth” vulnerabilities which are 12 risks identified in Bluetooth Low Energy-baseddevices that may crash the device, add interference in working, or allow access to an unauthorizeduser. The manufacturers affected by such attacks include Texas Instruments, NXP, Cypress, andmany more. In January 2020, the FDA raised awareness in GE’s Healthcare Clinical InformationCentral Stations and Telemetry Servers which are used mainly in health care facilities fordisplaying information, such as the physiologic parameters of a patient (temperature, heartbeat,blood pressure), and monitoring patient status from a central location. In October 2019, 11
vulnerabilities, named “URGENT/11” were recorded by a security firm in the third-party off-theshelf software component IPnet, a tool that supports network communications between computers.These vulnerabilities may allow anyone to remotely take control of the medical device and changeits function, causing a denial of service, or causing information leaks with logical flaws. The FDAalso expressed concerns for the Medtronic MiniMed insulin pumps (unauthorized access throughthe wireless network to control pump activities, June 2019), Medtronic cardiac implantablecardioverter defibrillators (ICDs) or cardiac resynchronization therapy defibrillators (CRT-Ds) (they do not use any kind of encryption, authorization, or authentication which may lead tounauthorized access) 7, and Abbott’s implantable cardiac pacemakers (unauthorized access toprogram commands in the implanted pacemaker, August 2017). 8Even though device manufacturers and software engineers are always working on patches,which are programs developed to repair software components, device manufacturers are nowengaging in proactive activities and using frameworks to secure devices and applications based onthe history of cybersecurity attacks and the concerns expressed by the FDA. The following sectiondescribes the standard Cybersecurity protocols and frameworks that device manufacturers shouldmeet to be compliant with the FDA regulatory requirements.4. Cybersecurity Protocols Recommended by the FDAThere are specific standards given by the International Organization for Standardization (ISO),International Electrotechnical Commission (IEC), and the Association for the Advancement ofMedical Instrumentation (AAMI) that the FDA approves and encourages developers to utilizewhile implementing a Cybersecurity framework. The selected framework should meet thesestandards, which should also be documented during the pre-market submission for FDA approval.Some of the standards include:4.1 ISO/IEC 81001-1 and IEC 80001-5-12ISO/IEC 81001-1 relates to the Health software and health IT systems safety, effectiveness, andsecurity – Part 1: Foundational principles, concepts, and terms, and IEC 80001-5-1 relates to theSafety, effectiveness, and security in the implementation and use of connected medical devices orconnected health software – Part 5: Security – Part 5-1: Activities in the product lifecycle.Both standards provide the terminology and an in-depth definition of components while designinga healthcare system. ISO/IEC 81001-1 provides the definitions for significant actors andcomponents in the software lifecycle process including customer, developer, hazard, hazardmanagement, residual risk (risk remaining after risk control), risk management, control,assessment, root cause, vulnerability, and weakness. The terminologies given by this standard canbe used as a reference mechanism while designing and implementing a Cybersecurity framework.IEC 80001-5-1 provides the actual measures that manufacturers should include in the designing,development, verification, and validation phases.4.2 IEC 60601-4-5 Guidance and interpretation – Safety-related technical securityspecifications for medical devices2The standard family IEC 60601 is mostly applicable to medical electrical devices with IEC 606014-5 being an exception. This standard applies to all medical products that are integrated into IT
networks, affecting Software as a Medical Device (SaMD). The standard provides three types ofsecurity level (SL) requirements: SL-T: The Target Security Level - for medical devices and networks to achieve the setprotection goal.SL-C: The Capability Security Level – for medical devices and networks while improvingIT security.SL-A: The Achieved Security Level, the level one achieves.At each security level, IEC 60601-4-5 proposes five levels, from SL 0 (nothing implemented) toSL 4, the highest level. The security levels help control the requirements and expenses of ITsecurity. The following table provides an example of the mapping between the aspects of securityrequirements and the corresponding security levels:Security RequirementsVPNsBasic Form/ Interface ValidationUser AuthorizationMulti-factor Authentication at all PointsRole-based AuthorizationMalware/ Virus/ Ransomware YesYesTable 1: An example specifying the mapping between the security requirements and thesecurity levels. 94.3 IEC 62304 Medical device software – Software life cycle processes2This standard provides a framework of life cycle processes with activities and tasks necessary forthe safe design and maintenance of medical device software. Also, it provides requirements foreach life cycle process. Each life cycle process is further divided into a set of activities, withmost activities further divided into a set of tasks. The major addition given by this standard to thepreviously developed standards for developing safe medical software is providing the processesfor software configuration management and software problem resolution.4.4 The Secure Product Design Life Cycle – Best Practices for Device Manufacturers2Utilizing practices developed in IEC 62443-4-1 Product Development Requirements, IEC 624434-2 Technical Security Requirements for industrial control system components, and IEC 61508Functional safety of electrical/electronic/programmable electronic safety-related systems, medicaldevice manufacturers can leverage these standards from the design to the deployment stage. Thesestandards emphasize on the design phase, verification, and testing phases.
Fig 1. The Secure Product Design Life Cycle4.5 AAMI TIR97/Ed. 1, Principles for medical device security – Post-market securitymanagement for device manufacturers2This Technical Information Report (TIR) based protocol addresses post-market security riskmanagement within the risk management framework defined by ANSI/AAMI/ISO 14971. Whileit is based on the ANSI/AAMI/ISO 14971 framework for medical device risk management, mostof the concepts apply to any healthcare product that requires post-market management of security.With this protocol, manufacturers can set up a system or enterprise level process to managesecurity. Also, this protocol provides a way of performing post market interactions with users.Other functionalities include creating post-market management security risk design features,integrating with Health Care Delivery Organizations (HDOs) security components like theirpolicies and technologies, and relaying manufacturer’s safety requirements to medical devicesdeployment team. Moreover, using this protocol, manufacturers can provide processes for: Monitoring devices with new vulnerabilitiesTake appropriate actions after assessing safety and security risksDevelop vulnerability disclosure processes and implement security patch managementDevelop plans for device replacement and retirement. 104.6 AAMI SW96/Ed. 1, Medical Devices – Application of security risk management tomedical devices2This standard is being developed based on the AAMI TIR97. Even though this project has beenapproved, it is currently on hold due to the development of AAMI TIR97.5. Pre and Post Market Submission Guidance5.1 Pre-market Submission Guidelines
The Pre-market submission FDA guidelines emphasize the “Level of Concerns”. These levelsindicate the level of risks associated with a device or a software system. FDA recommends thatthese levels should be determined before the mitigation of any identified relevant hazards. Theconcern levels include Major (Results in serious injury or death), Moderate (May result in minorinjury), or Minor (Minimal functional effect). Also, device manufacturers should describe howthey selected a specific level of concern. At every stage, each document shall address these levelsof concerns associated with potential risks in the system. Documentation based on Minor, Moderate, and Major Concerns: Level of Concerndocument, Software Description, Device Hazard Analysis, Traceability Analysis, andRevision Level History Documentation based on Moderate and Major Concerns: Architectural Design Chart,Software Design Specification (SDS), Software Development Environment Description,List of remaining software anomalies (Bugs or Defects) annotated with an explanation ofthe impact on safety or effectiveness, including operator usage and human factors. Software Requirements Specification (SRS): For Minor Level: Summary of functionalrequirements from SRS. For Moderate/ Major Level: Complete SRS document. Verification and Validation: For Minor Level: Software functional test plan, pass/failcriteria, and a summary of the test results. For Moderate/ Major Level: Description of V&Vactivities at the unit, integration, and system level. System-level test protocol for ModerateConcern. Unit, integration, and system-level test protocols for Major Concern.8Moreover, manufacturers should establish design inputs for their device related tocybersecurity and establish a cybersecurity vulnerability and management approach as part of thesoftware validation and risk analysis that is required by 21 CFR 820.30(g). The approach shouldappropriately address the following elements: Identification of assets, threats, and vulnerabilities,assessment of the impact of threats and vulnerabilities on device functionality and endusers/patients, Assessment of the likelihood of a threat and vulnerability beingexploited, determination of levels of concerns and suitable mitigation strategies, assessment ofresidual risk, and risk acceptance criteria.5.2 Post-market Submission GuidelinesAs medical devices and applications evolve, so do the risks associated with them. Hence, it isnot always possible to completely mitigate the risks only by using premarket controls.Cybersecurity risk management programs should focus on addressing vulnerabilities that avoidunauthorized access or the unauthorized use of information that is stored, accessed, or transferredfrom a medical device to an external recipient, resulting in patient harm.Manufacturers should be proactive when they identify vulnerabilities. When the product isrunning, manufacturers should implement measures including identifying sources ofvulnerabilities, monitor third party-software for new risks, and use a robust software lifecycle.Additionally, they should subject the updates and patches built for risk mitigation through theverification and validation phases. Also, they should establish a sophisticated process forvulnerability handling. Besides accepted protocols, the FDA recommends that manufacturers usethe ISAO (Information Sharing and Analysis Organization) platform and standards to share threatsthat affect the running medical devices. Sharing and spreading of such cybersecurity informationabout vulnerabilities results in a successful post-market cybersecurity surveillance program.8
To manage post-market cybersecurity risks for medical devices, the key measures are riskmanagement and quality management systems which are compliant with 21 CFR part 820. Also,the FDA recommends using a strong framework like NIST for Improving Critical InfrastructureCybersecurity which has a significant data flow for identifying and mitigating risks: Identity,Protect, Detect, Respond, and Recover. 116. Cyber Risks Mitigating MeasuresIn the early stages of development, medical device manufacturers should always select aCybersecurity framework that identifies components that could potentially cause data breaches. Aframework like NIST, which identifies risks and protects system against malicious data elements,responds and recovers after system has undergone attack. Also, with cybersecurity researchers,they should include the designed framework in every software development phase. Whilecapturing the system’s functional and security requirements, manufacturers should ensure theirsystem meets FDA’s device and software regulatory requirements.For information systems, the security measures can be initiated by maintaining a centralizedentity that performs profile access and identity management. Additionally, systems would be moresecure if the access is designed using multi-layered models like VPNs, multifactor, or token-basedauthentication. The information system mitigation part also includes designing a sophisticatedemployee training program, with logging and third-party assessment tools that providesinformation on links where users might have exposed the data. Manufacturers and softwareengineers should implement an extensive cyber-risks mitigation plan for overall data and systemprivacy and security. 12In the end, manufacturers should monitor third-party software components for newvulnerabilities throughout the product’s lifecycle, report issues to FDA or Homeland Security incase of new vulnerabilities, and also identify design verification and validation strategies forsoftware updates that are used to remediate vulnerabilities, including those related to Off-the-shelfsoftware. Major responsibilities fall on medical device manufacturers (MDMs) and health deliveryorganization (HDOs) when it comes to mitigating cyber-risks and vulnerabilities. MDMs shouldbe vigilant about new or old risks and hazards associated with their devices. HDOs shouldimplement measures for protecting their information systems and network with the latest availablecybersecurity frameworks. Both entities should add mechanisms for ensuring complete systemsecurity including device safety, quality and effectiveness.8 For any observed anomalies, it ismandatory for manufacturers and facility personnel to submit device reports to the FDA. Reportsmaybe also submitted voluntarily by patients, consumers, and healthcare professionals. 137. ConclusionPlatforms like IoT facilitate abilities such as continuous health monitoring and devicecontrol. But with recent developments in medical devices and applications, the flow of the datathrough public domains is increasing, making the system vulnerable. Indeed, devices which do notimplement authorization, data encryption and authentication are highly vulnerable. Hence,Cybersecurity becomes a vital factor to be considered as a part of system and data security. Basedon the past cybersecurity attacks and the concerns stated by FDA, there are tons of modernCybersecurity frameworks available in the market. Also, FDA has provided several protocolswhich device manufacturers can implement in their systems through which they will meet the FDA
Cybersecurity requirements. With protocols like IEC 60601-4 implemented in the system, FDAwould consider the device to be robust and fault tolerant against the malware and ransomwareattacks, thus securing the system.Our company, EMMA International, specializes in quality, regulatory, and compliancesolutions and services which also include providing the right guidance for including the correctCybersecurity frameworks, or verifying if the implemented Cybersecurity model meets the FDAstandards. If you have a medical device, or an application with Cybersecurity needs, our regulatoryand software experts can help ensure your device is FDA compliant. Call us today at 248-9874497 or email us at info@emmainternational.com for more information.
BibliographyDanny Palmer (Nov 2018) IoT security: Why it Will Get Worse Before It Gets Better. Retrieved on 09/19/2020from will-get-worse-before-it-gets-better/.1FDA. (2019) FDA Selection of Cybersecurity-related Standards in Development for Medical Devices. Retrievedon 09/19/2020 from https://www.fda.gov/media/123070/download#: :text 20clarity%20for%20users.2Danny Palmer (June 2019) Cybersecurity: These are the Internet of Things Devices that are Most Targeted byHackers. Retrieved on 09/19/2020 from rgeted-by-hackers/3National Cyber Security Center (NCSC) (June 2016) How cyberattacks work. Retrieved on 09/23/2020 attacks-work4Katie Adams (July 6, 2020) Healthcare providers that underwent cyberattacks in 2020 so far. Retrieved on09/23/2020 from -y/healthcare-providers-that- re IT News (2018) The biggest healthcare data breaches of 2018 (so far). Retrieved on 09/26/2020 est-healthcare-data-breaches-2018-so-far.6FDA (January 2020) Cybersecurity Vulnerabilities Affecting Medtronic Implantable Cardiac Devices,Programmers, and Home Monitors: FDA Safety Communication. Retrieved on 09/26/2020 -and-home7FDA. (March 2020) Cybersecurity. Retrieved on 09/27/2020 from center-excellence/cybersecurity8Johner Institute. IEC 60601-4-5: The standard for IT security, is it also for stand-alone software? Retrieved on09/27/2020 from -iec-62304/and-more/iec-60601-4-5/9AAMI (2019) AAMI TIR97: 2019. Principles for medical device security – Post-market security management fordevice manufacturers. Retrieved on 09/27/2020 from http://my.aami.org/aamiresources/previewfiles/1909 TIR97preview.pdf1011NIST. Cybersecurity Framework. Retrieved on 09/27/2020 from https://www.nist.gov/cyberframeworkNach Dave (December 2019) Cyberattacks on Medical Devices Are on the Rise—and Manufacturers MustRespond. Retrieved on 09/27/2020 from -riseand-manufacturers-must-respond12FDA. (August 2019) Medical Device Reporting (MDR): How to Report Medical Device Problems. Retrieved on09/27/2020 ical-device-problems13
Vulnerabilities in Medical Devices & Software Applications . Vulnerabilities can be defined as the data access points through which computer malware, worms, or viruses can be injected. . vulnerabilities, named "URGENT/11" were recorded by a security firm in the third-party off-the-shelf software component IPnet, a tool that supports .
Brownie Cybersecurity Explore cybersecurity by earning these three badges! Badge 1: Cybersecurity Basics Badge 2: Cybersecurity Safeguards Badge 3: Cybersecurity Investigator This Cybersecurity badge booklet for girls provides the badge requirements, background information, and fun facts about cybersecurity for all three Brownie
Mar 01, 2018 · ISO 27799-2008 7.11 ISO/IEC 27002:2005 14.1.2 ISO/IEC 27002:2013 17.1.1 MARS-E v2 PM-8 NIST Cybersecurity Framework ID.BE-2 NIST Cybersecurity Framework ID.BE-4 NIST Cybersecurity Framework ID.RA-3 NIST Cybersecurity Framework ID.RA-4 NIST Cybersecurity Framework ID.RA-5 NIST Cybersecurity Framework ID.RM-3 NIST SP 800-53
CSCC Domains and Structure Main Domains and Subdomains Figure (1) below shows the main domains and subdomains of CSCC. Appendix (A) shows relationship between the CSCC and ECC. Cybersecurity Risk Management 1-1 Cybersecurity Strategy 1-2 1- Cybersecurity Governance Periodical Cybersecurity Review and Audit 1-4 Cybersecurity in Information Technology
cybersecurity practices based on NIST's cybersecurity framework in fiscal year 2017. Agencies currently fail to comply with basic cybersecurity standards. During the Subcommittee's review, a number of concerning trends emerged regarding the eight agencies' failure to comply with basic NIST cybersecurity standards. In the
Like many programs at Sentinel, cybersecurity begins with executive sponsorship and the recognition that the program is a top, firm-wide, priority and that cybersecurity is every employee's job. Sentinel Benefits DOL Cybersecurity Best Practices Select elements of Sentinel's Cybersecurity Program include: Threat and Risk Mitigation
The 2020 Cybersecurity Report assesses the resources currently available to government entities to respond to cybersecurity incidents, identifies preventive and recovery efforts to improve cybersecurity, evaluates the statewide information security resource sharing program, and provides legislative recommendations for improving cybersecurity.
EBU and Cybersecurity EBU has a well-established Cybersecurity Committee and has developed numerous Recommendations in recent years: -R141 -Mitigation of distributed denial-of-service (DDoS) attacks -R142 -Cybersecurity on Connected TVs -R143 -Cybersecurity for media vendor systems, software and services
5 Program MODULE 1: Macro perspective on cybersecurity MODULE 2: Introduction to cyber security concepts MODULE 3: Identification of assets and risk concepts MODULE 4: Protection of assets and detection of attacks MODULE 5: Reaction and Recovery MODULE 6: Cybersecurity Law MODULE 7: Economic Evaluation of Cybersecurity Investments Cybersecurity risks and challenges on
