A ‘building code’ for building secure code in medical devices

Carl Landwehr portrait

Carl Landwehr

Last month, a broad mix of experts convened by THaW researcher Carl Landwehr convened in New Orleans to begin drafting a “building code” for medical-device software.  They’ve just released their report, and there is already talk about taking some of these ideas into the various standards bodies. Check out their report and feel free to leave comments on their site.  — dave

THaW at the mHealth Privacy & Security Symposium

Perhaps the largest annual event related to mHealth is the mHealth Summit, held near Washington DC.  Today, the summit kicked off with a Privacy & Security Symposium, including a panel on Medical Device Security anchored by both Kevin Fu and Darren Lacey from the THaW team.  Kevin, Darren and the other panelists spoke about some of the security concerns that medical devices pose for patients, clinicians, and hospitals.  The audience brought together a broad mix of medical practitioners, device and software vendors, security professionals, and computer scientists.

photo of the panelists

Kevin Fu and Darren Lacey at the center of a panel session at the mHealth Summit.

Constructing a ‘building code’ for medical device software security

The following summary of the recent ‘building code’ workshop sponsored in part by THaW held on November 19-21, 2014 is provided by Dr. Carl Landwehr —

Forty people with diverse backgrounds in medical device software development, standards, regulation, security, and software engineering met in New Orleans November 19-21 with the goal of constructing a “building code” for medical device software security and a related research agenda. The workshop was sponsored by National Science Foundation through both the Trustworthy Health and Wellness (THaW) center and a separate workshop grant to George Washington University’s Cyber Security Policy and Research Institute (CSPRI) as well as the IEEE Computer Society’s Cybersecurity initiative.

The idea of exploiting building code metaphor originated with THaW’s Carl Landwehr, who organized the meeting with the help of a Steering Group that included THaW leadership as well as several others from the worlds of medical devices, software engineering, and security. Tom Haigh, recently retired from Adventium, served as Vice-Chair.

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. Inspectors must be knowledgeable and skilled, but the training requirement is not burdensome, and decisions as to whether a building meets the code or not are typically straightforward. Codes also take account of different domains of use of structures: code requirements for single-family dwellings differ from those for public buildings, for example. 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.

The workshop aimed to develop an analog to building codes focused on the security properties of software rather than the structure and characteristics of physical building.  The objective of this code for software security is to increase assurance that software developed for the domain of medical devices will be free of many of the security vulnerabilities that plague software generally.  Evidence to date is that a large fraction of exploitable security flaws are not design flaws but rather implementation flaws. An initial building code for medical device software security could focus on assuring that the final software that operates the device is free of these kinds of flaws, although it could address aspects of the development process as well.  For example, the code might specify that modules written in a language that permits buffer overflows be subject to particular inspection or testing requirements, while modules written in type-safe languages might require a lesser degree of testing but a stronger inspection of components that translate the source language to executable form.

About 35 separate items were proposed for inclusion in an initial draft building code. Although the final report is still in development, only about half of these elements are likely to be included in the consensus version of the code.

Several participants in the workshop who are active in related standards bodies and professional societies have indicated an interest in moving the code forward in those groups.

FDA visits NIST federal advisory committee on security and privacy (audio available)

As previously referenced in the official blog of the Ann Arbor Research Center for Medical Device Security,the NIST Information Security and Privacy Advisory Board (ISPAB) held a public panel on October 24, 2014 entitled “Updates on Embedded Device Cybersecurity: Medical Devices to Automobiles.”

Professor Kevin Fu has provided an audio recording of this meeting that can be found here — http://blog.secure-medicine.org/2014/10/fda-visits-nist-federal-advisory.html