1. Home‎ > ‎

C. Workshop Call for Participation

Call for Contributions and Participation

Invitational Workshop to Create A Building Code for Medical Device Software Security

November 19-21 2014

Hyatt French Quarter, New Orleans

1. Purpose

The aim of this workshop is (1) to establish an initial consensus among industry and academic participants on the recommended components of a “building code” that would be appropriate to reduce significantly reduce the vulnerability of medical devices to malicious attacks, and (2) to establish a research agenda for the creation of evidence that could justify the inclusion of additional elements in such a code. The workshop will be held under the auspices of the IEEE Computer Society’s Cybersecurity Initiative,  with participation from NSF’s Trustworthy Health and Wellness (THaW) project; additional support is being sought from the NSF Secure and Trustworthy Cyberspace program.

2. What might a building code for medical device software security look like?

Building codes applied to physical structures generally grow out of industry and professional society groups – suppliers, builders and architects – rather than from government, although adoption of codes by government provides a 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 take account of different domains of use of structures: code requirements for single-family dwellings differ from those for public buildings, for example.

Following the ideas expressed in [1] we aim to develop an analog to these processes that will improve 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.

3. Considerations for including a particular requirement in a building code for medical device security

1. Effectiveness. The first criterion should be the ability of the required item to reduce the vulnerability of software to exploitation. Specific evidence should be available to support claims of effectiveness.

2. Ease of evaluation.  Requirements that are effective but require unusual expertise, time, or other resources to evaluate are not appropriate for inclusion in the code.

3. Scope. Requirements affecting only a narrow scope of vulnerabilities may not be appropriate to incorporate.

4. Participants sought

To succeed, the workshop needs participation from (1) industry personnel familiar with the architecture and tools used to build medical devices and the software that controls them, (2) people familiar with the history of medical device regulation in general and people familiar with the history of computer security regulation, (3) researchers and practitioners familiar with cybersecurity issues generally and with security issues in medical device software in particular, and (4) experts in relevant aspects of software engineering, including requirements, design, and (especially) implementation, test, and validation/verification methods.

5. Workshop organization and products

The meeting will be organized as two-day event with approximately 40 invited participants, starting in the evening of the first day (Nov. 19) and ending in the afternoon two days later (Nov 21). The meeting will open with a dinner session accompanied by an invited talk or panel on the history and current state of official guidance on the security of medical device software.  The next day will open with a general talk on the concept of a building code for security-critical software that will address the types of requirements a building code might include and the possible basis for deciding whether a particular element should be included in the code. Following this introduction, a series of short talks proposing possible elements of the code will be presented, based on submissions received in advance of the meeting.

In afternoon breakout sessions, the participants will be asked to discuss the proposed elements and to assess the strength of the evidence for including each proposed item in the code. When the group consensus is that stronger evidence is needed, research topics that might help establish that evidentiary basis will be identified.  At the end of the afternoon, groups will report on their progress in a brief plenary session. 

The breakout sessions will reconvene on the final morning of the workshop to consider the results of the plenary session and any evening discussions. The meeting will close with a two-hour plenary session in which consensus on an initial building code and research agenda will be sought.

Following the meeting, the Chair and Vice-Chair, in consultation with the workshop participants and Steering Committee will develop a report on the workshop documenting the initial draft building code and research agenda. The report be placed on a George Washington University website and will be published by the IEEE as well.

6. Where to send your contribution / request for invitation

If you are interested in participating, please send a note of not more than 600 words explaining (1) which of the four groups listed above you would represent and (2) at least one requirement you think would be appropriate to discuss at the workshop as a candidate for an initial building code, as well as evidence supporting the effectiveness of that requirement. If you are interested in the workshop but don’t have a specific element to propose, please include a description of your role in medical device software development or in assuring software security. E-mail this information to:


7. Travel Support

Travel grants will be available for those who need support to attend the workshop. The IEEE Computer Society's Cybersecurity Initiative (also sponsor of the IEEE Center for Secure Design) and the National Science Foundation will provide support for this effort, for which the organizers are grateful.

8. Reference

1. Landwehr, C. E. “A Building Code for Building Code: Putting What We Know Works to Work,” Proc. 29th Annual Computer Security Applications Conference (ACSAC), New Orleans LA., ACM, NY, pp.139-147. Available at: http://www.landwehr.org/2013-12-cl-acsac-essay-bc.pdf

IEEE Center for Secure Design