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".
Register for Dark Reading Newsletters
Dark Reading Live EVENTS
INsecurity - For the Defenders of Enterprise Security
A Dark Reading Conference
While red team conferences focus primarily on new vulnerabilities and security researchers, INsecurity puts security execution, protection, and operations center stage. The primary speakers will be CISOs and leaders in security defense; the blue team will be the focus.
White Papers
Video
Cartoon Contest
Write a Caption, Win a Starbucks Card! Click Here
Latest Comment: No, no, no! Have a Unix CRON do the pop-up reminders!
Current Issue
Security Vulnerabilities: The Next Wave
Just when you thought it was safe, researchers have unveiled a new round of IT security flaws. Is your enterprise ready?
Flash Poll
The Impact of a Security Breach 2017
The Impact of a Security Breach 2017
Despite the escalation of cybersecurity staffing and technology, enterprises continue to suffer data breaches and compromises at an alarming rate. How do these breaches occur? How are enterprises responding, and what is the impact of these compromises on the business? This report offers new data on the frequency of data breaches, the losses they cause, and the steps that organizations are taking to prevent them in the future.
Slideshows
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2017-0290
Published: 2017-05-09
NScript in mpengine in Microsoft Malware Protection Engine with Engine Version before 1.1.13704.0, as used in Windows Defender and other products, allows remote attackers to execute arbitrary code or cause a denial of service (type confusion and application crash) via crafted JavaScript code within ...

CVE-2016-10369
Published: 2017-05-08
unixsocket.c in lxterminal through 0.3.0 insecurely uses /tmp for a socket file, allowing a local user to cause a denial of service (preventing terminal launch), or possibly have other impact (bypassing terminal access control).

CVE-2016-8202
Published: 2017-05-08
A privilege escalation vulnerability in Brocade Fibre Channel SAN products running Brocade Fabric OS (FOS) releases earlier than v7.4.1d and v8.0.1b could allow an authenticated attacker to elevate the privileges of user accounts accessing the system via command line interface. With affected version...

CVE-2016-8209
Published: 2017-05-08
Improper checks for unusual or exceptional conditions in Brocade NetIron 05.8.00 and later releases up to and including 06.1.00, when the Management Module is continuously scanned on port 22, may allow attackers to cause a denial of service (crash and reload) of the management module.

CVE-2017-0890
Published: 2017-05-08
Nextcloud Server before 11.0.3 is vulnerable to an inadequate escaping leading to a XSS vulnerability in the search module. To be exploitable a user has to write or paste malicious content into the search dialogue.