OPTIMIZING CYBERSECURITY RISK IN MEDICAL CYBER-PHYSICAL DEVICES.

• Author: Yoo, Christopher S.

TABLE OF CONTENTS INTRODUCTION 1516 I. THE UNIQUE PROBLEMS OF SOFTWARE AND CYBERSECURITY IN MEDICAL DEVICE REGULATION 1520 II. LEGAL FRAMEWORK GOVERNING THE FDA'S CONSIDERATION OF NONTHERAPEUTIC COSTS 1524 A. Prohibition of Cost Considerations 1527 B. Statutory Ambiguity 1530 C. Current Practices 1533 1. Nonfinancial Costs 1533 2. Speed of Review 1534 3. Economic Impact Analyses of Proposed Regulations 1535 4. Implicit Consideration in Product Approval Decisions 1536 D. General Guidance on Software 1536 E. Specific Guidance on Cybersecurity Management 1539 III. APPROACHES TO DETERMINING THE OPTIMAL LEVEL OF CYBERSECURITY 1543 A. The Case of Cybersecurity 1544 B. Possible Approaches to Taking Economic Cost into Account 1544 1. The FTC's Cost-Benefit Test 1545 2. Tort Standards 1545 3. Incremental Cost Effectiveness Ratios (ICERs) 1549 C. Choosing the Best Approach 1552 CONCLUSION 1553 INTRODUCTION

"Yes, terrorists could have hacked Dick Cheney's heart." (1) The former vice president's heart implant, with its wireless functionality, could have resulted in an assassination." Recognizing this possibility, Cheney's doctor had to order the wireless functionality of the heart implant to be disabled. (3)

Cheney's story is just one example of the risk of deadly cyber-security attacks on connected medical devices. Numerous other reports and studies have shown how cybersecurity threats endanger lives. (4) Researchers have shown that a hacker can remotely kill a person by causing an implanted insulin pump to release a deadly dose of insulin or by making a pacemaker release a heart-stopping electric charge. (5)

These connected medical devices present special cybersecurity risks because they are part of cyber-physical systems. In cyber-physical systems, devices not only interact with other networked devices but also receive and respond to input from the physical environment. (6) Other prominent examples include autonomous vehicles, smart grid sensors, and robotics systems. (7)

In an increasingly cyber-physical world, traditional notions of cybersecurity fall short. When devices were purely cyber, the predefined nature of the inputs they could receive made their behavior easier to predict and different systems' responses to those inputs easier to validate. The data fed into cyber-physical systems are not so rigidly constrained, as the physical environment involves realworld events that are theoretically unbounded and do not always stay within predictable limits. (8) Body temperature, for example, almost always stays within a certain range, yet unprecedented readings can and do occur. (9) The unbounded nature of the data prevents designers from testing how a cyber-physical device will function in every possible real-world scenario, making it impossible to rule out black swan events with low probability but high impact. (10)

In addition, threats to medical cyber-physical devices often involve deliberate actions by malicious actors whose novel attacks cannot always be anticipated. (11) The fact that cyber-physical systems can be networked across hospitals and third-party institutions raises the stakes still further. (12) The large user base increases the probability of breaches as well as the potential magnitude of the resulting harm. As malicious actors constantly invent new zero-day attacks, designers must plan for ever-evolving changes to cybersecurity needs. (13)

The inability to eliminate cybersecurity risks completely means that a designer can always add additional security features to plan for an ever-broader range of scenarios. Each increase in cybersecurity comes at a cost. Besides the obvious monetary cost, the additional processing power, storage, and battery power that new cybersecurity features require may hinder a device's functionality, posing costs to health. (14) For example, a security feature that increases the size of a device or increases its power consumption could make the device more dangerous or reduce its effectiveness as a bodily implant. (15) In a world of limited resources, additional security improvements must end at some point.

Because designers cannot proactively eliminate every cybersecurity flaw, they need a framework for determining what constitutes an acceptable level of risk to determine when they can stop adding security. Cybersecurity thus inevitably requires some type of costbenefit analysis to inform the optimal level of cybersecurity.

Federal regulators, however, have offered no such solution in defining cybersecurity standards for medical devices. The U.S. Food and Drug Administration (FDA), which regulates medical devices, offers only nonbinding guidance documents recommending certain cybersecurity features. (16) Moreover, these documents do not address the optimal level of security or make any mention of cost considerations. (17) In fact, the FDA has interpreted its own authority in a limited way, operating on an internal policy that the agency cannot consider financial costs when evaluating products. (18)

The inadequacy of the FDA's cybersecurity regulation is just one symptom of its troubling record with software. Commentators have long noted that the FDA's overarching regulatory approach is illfitted for software, creating difficulties for designers of medical device software. (19) Having abandoned multiple attempts to create a separate approach to software, the FDA seems to know that it has a problem with software and cybersecurity regulation. (20) But the agency has yet to address the issue.

A logical solution for the agency would involve some type of costbenefit analysis to inform the optimal level of cybersecurity risk, but the FDA does not conduct economic cost-benefit analyses. (21) Instead, the FDA has interpreted its authorizing statute as prohibiting consideration of economic costs, inhibiting the agency's ability to weigh these costs with benefits. (22)

The agency's resulting approach to cybersecurity means a lack of clarity for medical device designers and potentially unsafe or inefficient devices. (23) This Article tackles this problem by recommending approaches that the FDA can use to define the optimal level of cybersecurity, taking into account the costs and benefits of potential cybersecurity features.

This Article proceeds in three parts. Part I highlights the unique challenges of medical device cybersecurity and their poor fit within existing regulatory approaches. Part II examines the existing legal constraints on the FDA's ability to set standards that balance costs and benefits. Drawing from statutory text and case law, we argue that the FDA can, in fact, weigh economic costs when evaluating products and that doing so is particularly important in the context of cybersecurity. Finally, Part III discusses three potential approaches the FDA can implement to determine the optimal level of cybersecurity. We explore the implications of each approach and conclude that the FDA's best option is to adopt the cost-benefit test used by the Federal Trade Commission (FTC). Regardless of which option the FDA chooses, however, the crucial point is that the FDA must use a balancing test that ensures the optimal level of cybersecurity in medical devices.

1. THE UNIQUE PROBLEMS OF SOFTWARE AND CYBERSECURITY IN MEDICAL DEVICE REGULATION

   Cybersecurity is a far cry from the traditional medical risks that the FDA regulates. As a result, the FDA's regulatory framework provides an insufficient approach for optimizing medical device cybersecurity.

   The FDA's troubling record with cybersecurity is no surprise given the agency's troubling record with software in general. The FDA's regulation of medical devices originated in a time when devices included insubstantial software. (24) As one expert testified to Congress, FDA staff saw software as "some kind of new bedpan." (25) Since then, software has come to play significant roles in medical devices. But despite radical differences between software and traditional hardware, the FDA continues to regulate both under the same framework, "like forcing a round peg into a square hole." (26) As a result, the FDA's regulation of software has often left medical software developers in a state of confusion. (27)

   The current framework for FDA regulation of medical devices traces back to the Medical Device Amendments of 1976. (28) The statute established three classes of devices based on risk. (29) Class I devices pose the lowest risk, presenting "minimal potential for harm" and often featuring a simple design, such as elastic bandages. (30) These devices require only general regulatory controls, and most are exempt from the FDA regulatory process. (31) Class II devices pose more risk and involve more complex designs, such as pregnancy test kits. (32) Before marketing a Class II device, a manufacturer must show that the device is "substantially equivalent" to--meaning as safe and effective as--a legally marketed device. (33) Class III devices have life-sustaining functions or "present potential unreasonable risk of illness or injury." (34) Pacemakers and other implantable devices fall into this high-risk class. (35)

   Software, however, was initially not seen as a major element of patient care and did not fit neatly into the FDA's three-tier device classification system. As medical devices increasingly transitioned from consisting only of hardware to incorporating software as critical elements of the device, the FDA began to recognize the challenges of software, noting in 1996 that according to an agency study of software-related recalls from fiscal years 1983 to 1991, "over 90 percent of all software-related device failures were due to designrelated errors." (36)

   The FDA's approach to software regulation presents many problems given the differences between software and hardware. For example, hardware devices tend to have an easily defined purpose, while software can have numerous and interdependent intended uses, both related and...