Endpoint

3/4/2015
10:30 AM
Greg Shannon
Greg Shannon
Commentary
Connect Directly
Facebook
Twitter
RSS
E-Mail vvv
100%
0%

A Building Code For Internet of Things Security, Privacy

In the fast-emerging IoT, medical device safety is reaching a critical juncture. Here are three challenges InfoSec professionals should begin to think about now.

Medical devices -- particularly those worn on or in the body -- are probably the most personal aspects of the emerging Internet of Things (IoT) and should be as secure and private as possible. Certainly, attention to this new challenge is well-warranted, given current events and trends.

Consider the scale of mortality in the medical device field in comparison to the advent of mass transportation via airplanes and automobiles in the early 20th century. As a recent, front-page article in The New York Times, “Hacked vs. Hackers: Game On,” noted:

“… the number of airplane deaths per miles flown … decreased to one-thousandth of what it was in 1945 with the advent of the Federal Aviation Administration in 1958 and stricter security and maintenance protocols.” Meanwhile, “there has been more than a 10,000-fold increase in the number of new digital threats over the last 12 years.”

Headlines that detail the breaching of public and private computer networks, the theft of data, the distribution of malware, and malicious computer and network attacks are legion. And there’s no reason to think that wearable or implanted medical devices are immune to this trend. In fact, another article from The New York Times, “A Heart Device is Found Vulnerable to Hacker Attacks,” established that a malicious intrusion into a combination heart defibrillator and pacemaker was indeed possible ( albeit expensive, computing-intensive and time-consuming) as far back as 2008.

Clearly, the operations and data relating to these devices must be protected for the patient’s health. But it’s also a legal requirement imposed by HIPAA, the Health Insurance Portability and Accountability Act of 1996. Thus our challenge crosses multiple domains, including medicine, computing, law and ethics, to name but a few.

Authentication and verification
One of the obvious challenges in this field, for example, is low-power and/or bi-directional authentication and verification. How do I know that the device’s data readout is authentic? How does the device know that it’s presenting data to an authorized user? Challenges of this sort are common in the cyber domain. But in a mobile, small form factor, underlying challenges include low power, limited processing and data storage, and air interfaces and protocols. This is essentially an engineering challenge that will be solved.

Another concern stems from legacy devices. When the Food and Drug Administration (FDA) approves a device, it is essentially approved forever. So whatever legacy device or software was in use at the time of approval continues in use. Though we can expect obsolescence and device turnover, we can also expect lag time during which those devices and/or software may be vulnerable. Security and privacy in a mobile medical device, as in other examples, are likely to be optimal when they’re tightly integrated with operations.

For security professionals, there are already a number of resources for raising industry awareness and increasing personal knowledge of IoT design best practices. An IEEE Computer Society Cybersecurity Initiative workshop in New Orleans, for example, focused on “Building Code for Medical Device Software Security” in a paper by Carl Landwehr, lead research scientist at the Cyber Security Policy and Research Institute (CSPRI) at George Washington University. The “A Building Code for Building Code” paper suggests known, effective measures for writing secure software, using medical devices as the first application. Although his specific prescriptions are hypothetical at this point, they make sense and are being explored.

I find the metaphor of “building codes” compelling because it captures the value of a standardized approach to security and privacy in medical devices, wearable or otherwise. One aspect of Landwehr’s approach is to incorporate programming language that integrates operational and security approaches.

In addition, the IEEE Cybersecurity Initiative’s Center for Secure Design’s recent paper, “Avoiding the Top Ten Software Security Design Flaws,” addresses issues that apply to mobile medical device design.

The evolution of health data
Not all solutions lie within the device itself, however. In order to use individual health data to draw conclusions about a population in general, a secure means of data sampling may also evolve. This approach is explained in “RAPPOR: Randomized, Aggregatable, Privacy-preserving Ordinal Response,” a technology for crowdsourcing statistics from end-user client software, anonymously, with strong privacy guarantees that allows “the forest of client data to be studied, without permitting the possibility of looking at individual trees.”

An effort I was not involved in, but which demonstrates the broad interest in this topic, was a workshop held this past October: Collaborative Approaches for Medical Device and Healthcare Cybersecurity. The effort was sponsored by the Food & Drug Administration/Center for Devices and Radiological Health, the Department of Homeland Security/C3 Voluntary Program, and the Department of Health and Human Services/Critical Infrastructure Protection Program.

Any investments in meeting the challenges inherent in secure and private mobile medical devices will pay dividends with wide application to other less critical domains. But it’s important to understand that medical device security and privacy is a current concern, not a future one. While focused work is currently under way, these efforts will need continued support and attention. We have an exciting opportunity to meet a relatively new, evolving challenge. And complacency is not one of our options.

Dr. Greg Shannon is chair, IEEE Cybersecurity Initiative and the Chief Scientist for the CERT(r) Division at Carnegie Mellon University's Software Engineering Institute, where his role is to expand the division's research results, impact, and visibility. Outside of CERT, ... View Full Bio
Comment  | 
Print  | 
More Insights
Comments
Newest First  |  Oldest First  |  Threaded View
dhaivid3
50%
50%
dhaivid3,
User Rank: Apprentice
3/17/2015 | 11:20:45 AM
Re: lame > Who's got a better name for the IoT?
Ooh, the acronyms are going to keep coming out of the woodwork. The papers "The Things in the Internet of Things" and "Things in the Internet of Things: Towards a Definition" are some of the recent attempts to get to the core of the keyword 'Things' in the IoT phrase, and that is just ONE part of the phrase.
Marilyn Cohodas
50%
50%
Marilyn Cohodas,
User Rank: Strategist
3/10/2015 | 8:55:21 AM
Re: lame > Who's got a better name for the IoT?
I always thought "Internet of Things" was just an abbreviated 'Internet of Everything." But you are right, 1eustace, another buzz word willl no doubt enter our vocabulary and be just as annoying. The good news is that some of the most overused cliches have practically disappeared. Remember the Information Highway? #cringe
1eustace
50%
50%
1eustace,
User Rank: Strategist
3/9/2015 | 3:28:57 PM
Re: lame > Who's got a better name for the IoT?
Don't worry, it's potential replacement "Internet of Everything" or IoE is already taking roots and soon you will read about IoT as much as you read about M2M today.  Point is it is a concept (connectivity and its evolution) with appellation to feed the latest buzz.  I'll bet it's replacement will be no less annoying.  
prospecttoreza
50%
50%
prospecttoreza,
User Rank: Strategist
3/6/2015 | 9:42:42 AM
How come connected medical devices are 'fast emerging'?
They've been around for years and years. Besides, were is 'the building code' ??? I thought there will be at least a passing reference to the actual standard or best practices. Very disappointing.
Marilyn Cohodas
50%
50%
Marilyn Cohodas,
User Rank: Strategist
3/5/2015 | 10:20:07 AM
Re: lame > Who's got a better name for the IoT?
Agree that the term is gattinga tad overused, but it is a pretty good description of the next (or current) big thing in technology. Anyone have a better idea?
n0md3plum
50%
50%
n0md3plum,
User Rank: Apprentice
3/4/2015 | 7:36:10 PM
lame
I hate that term "Internet of things".
Want Your Daughter to Succeed in Cyber? Call Her John
John De Santis, CEO, HyTrust,  5/16/2018
Don't Roll the Dice When Prioritizing Vulnerability Fixes
Ericka Chickowski, Contributing Writer, Dark Reading,  5/15/2018
Why Enterprises Can't Ignore Third-Party IoT-Related Risks
Charlie Miller, Senior Vice President, The Santa Fe Group,  5/14/2018
Register for Dark Reading Newsletters
White Papers
Video
Cartoon Contest
Write a Caption, Win a Starbucks Card! Click Here
Latest Comment: "Security through obscurity"
Current Issue
How to Cope with the IT Security Skills Shortage
Most enterprises don't have all the in-house skills they need to meet the rising threat from online attackers. Here are some tips on ways to beat the shortage.
Flash Poll
[Strategic Security Report] How Enterprises Are Attacking the IT Security Problem
[Strategic Security Report] How Enterprises Are Attacking the IT Security Problem
Enterprises are spending more of their IT budgets on cybersecurity technology. How do your organization's security plans and strategies compare to what others are doing? Here's an in-depth look.
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2018-11232
PUBLISHED: 2018-05-18
The etm_setup_aux function in drivers/hwtracing/coresight/coresight-etm-perf.c in the Linux kernel before 4.10.2 allows attackers to cause a denial of service (panic) because a parameter is incorrectly used as a local variable.
CVE-2017-15855
PUBLISHED: 2018-05-17
In Qualcomm Android for MSM, Firefox OS for MSM, and QRD Android with all Android releases from CAF using the Linux kernel, the camera application triggers "user-memory-access" issue as the Camera CPP module Linux driver directly accesses the application provided buffer, which resides in u...
CVE-2018-3567
PUBLISHED: 2018-05-17
In Qualcomm Android for MSM, Firefox OS for MSM, and QRD Android with all Android releases from CAF using the Linux kernel, a buffer overflow vulnerability exists in WLAN while processing the HTT_T2H_MSG_TYPE_PEER_MAP or HTT_T2H_MSG_TYPE_PEER_UNMAP messages.
CVE-2018-3568
PUBLISHED: 2018-05-17
In Qualcomm Android for MSM, Firefox OS for MSM, and QRD Android with all Android releases from CAF using the Linux kernel, in __wlan_hdd_cfg80211_vendor_scan(), a buffer overwrite can potentially occur.
CVE-2018-5827
PUBLISHED: 2018-05-17
In Qualcomm Android for MSM, Firefox OS for MSM, and QRD Android with all Android releases from CAF using the Linux kernel, a buffer overflow vulnerability exists in WLAN while processing an extscan hotlist event.