Inspector General's 2016 Work Plan: A Cybersecurity Wake-Up Call To Medical Device Designers

By Shahid Shah, president & CEO, Netspective Communications
Follow me on Twitter @ShahidNShah

The U.S. Department of Health and Human Services (HHS) Office of Inspector General’s (OIG) Work Plan for 2016, released early in November, summarizes OIG’s efforts to improve the overall effectiveness of more than 100 programs administered by HHS. In addition to scrutinizing Centers for Medicare & Medicaid Services (CMS) reimbursement for fraud and cost-cutting opportunities, OIG will put medtech cybersecurity under the microscope.

Specifically, the government watchdog agency intends to determine whether FDA is doing enough to secure networked medical devices at hospitals — to protect both patient data and safety. OIG also expects device manufacturers to be more accountable by providing a security disclosure statement for each of their products, built upon information gleaned from threat assessment, threat modeling, and vulnerability assessment tasks.

FDA To Scrutinize Connected Devices And Hospital Networks More Closely

This new addition to the work plan likely will require the most immediate attention from device designers, because the FDA will be paying closer attention. The work plan explains that OIG will: “…examine whether FDA’s oversight of hospitals’ networked medical devices is sufficient to effectively protect associated electronic protected health information (ePHI) and ensure beneficiary safety.”

OIG’s scrutiny will extend to hardware and software of connected medical devices, as well as hospitals’ networks, regardless of whether connections are wired or wireless. As the work plan explains, “Computerized medical devices, such as dialysis machines, radiology systems, and medication dispensing systems that are integrated with electronic medical records (EMRs) and the larger health network, pose a growing threat to the security and privacy of personal health information.”

This increased attention to secure connectivity has been made necessary by the trend of medical devices — often led by regulated wearables — promising electronic health information (EHR) integration. The first step toward this healthcare provider and user-demanded integration is network connectivity. Unfortunately, unless a device was conceived and designed for a networked age, adding networking as a bolt-on creates significant opportunities for potentially significant security holes.

Device Manufacturers Must Enhance Documented Cybersecurity Measures

Medical device manufacturers soon will be responsible for providing a security disclosure statement. Per OIG’s the work plan:

Medical device manufacturers provide Manufacturer Disclosure Statement for Medical Device Security (MDS2) forms to assist health care providers in assessing the vulnerability and risks associated with ePHI that is transmitted or maintained by a medical device. (OAS; W-00-16-42020; expected issue date: FY 2016)

In order for device designers to provide useful disclosure statements, they’ll need to expand their threat assessment, threat modeling, and vulnerability assessment tasks — or start performing those tasks, if they haven’t already. If this review is conducted during device design, it’s not too difficult, but performing the tasks on existing equipment is often time-consuming.

For example, device customers are willing to pay significantly more for devices that help fill clinical documentation into EHRs. This is because the CMS Meaningful Use (MU) reimbursements program has relegated data entry duties to clinical providers in some cases, leading to anger over having to enter the data multiple times – once in devices and then again in EHRs – to wasted time, and to more errors that could potentially harm patients.

If EHR vendors and customers start to depend solely on the data coming from connected medical devices, then workflows and safety protocols will be tied to that data, as well. As data from the devices becomes tied to patient care, its reliability — whether for security reasons or patient safety reasons — becomes even more important. Once care plans and protocols are automated through networked devices, it’s not hard to see that the next step after a security disclosure statement will be a patient data safety statement. Designers should act with foresight and plan for safety risk and security vulnerability assessments.

Vulnerabilities To Prioritize

A number of cybersecurity and medical device engineers, myself included, convened late in 2014 for a workshop to discuss what a “building code” for medical device software security might look like. Many of us aren’t familiar with building codes, but we benefit from safe buildings and structures every day, and the parallels between safe buildings and safe medical devices are not difficult to see.

Consider this excerpt from the workshop’s final report:

Building codes for physical structures grow out of industry and professional society groups – suppliers, builders and architects – rather than from government, although adoption of codes by government provides the legal basis for enforcement. Building codes generally apply to designs, building processes, and the finished product. Code enforcement relies on inspections of structures during construction and of the finished product and also on certification of the skills of the participants in the design, construction, and inspection processes. Codes also account for different domains of use... Although building codes arose largely from safety considerations (e.g. reducing the risk of widespread damage to cities from fires, hurricanes, or earthquakes), security from malicious attack has also motivated some aspects of building codes.

IEEE CSI and NSF sponsored that workshop and used its findings to create Building Code for Medical Device Cyber Security, which documents the vulnerabilities device designers and software engineers should prioritize. The code’s introduction further explains the parallels between regulating structures and regulating medical device cybersecurity:

Metaphorically, the aim is to specify the needed properties of the bricks used to build the structure, not its architecture. The reason for focusing on the “bricks” at this time is that the majority of vulnerabilities actually exploited in cyberattacks are errors in implementation rather than design. By focusing on the desired implementation properties, this code aims to ensure that these bricks are indeed sound in that they are free of most vulnerabilities currently exploited.

Here are some of the core subject areas mentioned in the report (verbatim):

1. Elements intended to remove / avoid flaws at the design stage

1. Secure random numbers – use of non-random seeds can render cryptographic mechanisms ineffective and permit attackers to spoof, tamper, or disclose sensitive data
2. Full recognition of inputs before processing – exploitation of input-handling code by maliciously crafted inputs
3. Least operating system privilege – exploitation of over-privileged processes

2. Elements intended to avoid / detect / remove specific types of vulnerabilities at the implementation stage

1. Use of memory-safe languages
2. Language subsetting
3. Automated memory safety error mitigation and compiler-enforced buffer overflow elimination
4. Use of secure coding standards
5. Automated thread safety analysis
6. Automated analysis of programs (source/binary) for critical properties
7. Accredited cryptographic algorithms and implementation
8. Modified condition decision coverage
9. Operational use case identification and removal of unused functions

3. Elements intended to assure software / firmware provenance and integrity, but not to remove flaws in code

1. Digitally signed firmware and provenance (supply chain)
2. Software/firmware update validation
3. Whitelisting

4. Elements intended to impede attacker analysis or exploitation but not necessarily remove flaws

1. Non-executable data pages
2. Anti-tamper for hardcoded secrets / keys / data within medical device software

5. Elements intended to enable detection / attribution of attack

1. Security event logging

6. Elements intended to assist in safe degradation of function in face of attack 

7. Elements intended to assist in restoration of function after attack

8. Elements intended to support maintenance of operational software without loss of integrity

9. Elements intended to support privacy requirements

Securing medical devices and associated connected software will not be easy, but it’s definitely possible with the right processes, procedures, technology, and expertise.

So, where should you start? The biggest gap in most medical device designers’ cybersecurity toolkit is a lack of risk-focused awareness. Here’s what device product management leadership should do immediately:

• Document the cyber risks you’re going to track (and at some point mitigate). Initially, don’t worry about the solution(s) – just focus on the risks catalog.
• Consider creating a cyber risk (including patient privacy) traceability matrix similar to a requirements traceability matrix (RTM). This will help you understand which requirements are likely to be the riskiest from a cyber security perspective. You can then start to document, for your support staff and for clients and their support staff, how to configure certain features more safely.
• Create a threat model for the device in specific scenarios, and how the threats map to the risks you’re tracking. This is probably the most important technical deliverable. If you don’t have a threat profile, threat model, or threat matrix created, it means that you won’t be able to prioritize your work. Keep in mind that the threat model for your device in one networked environment may not be the same as another, so you may need a model per customer deployment.

If you have other suggestions about where device designers should start their journey to safer and more secure devices, please share them in the Comments section below or reach out to me directly.

Shahid Shah is an award-winning cybersecurity mentor and medical device hardware / software design coach with 25 years of technology strategy and engineering experience. You can reach him via Twitter or email.