Tag Archives: mobile

Killed by code – back to the future

Back in 2011, I thought it’s only a question of time before we have a drive by execution of a politician with an ICD (implanted cardiac device).

Fast forward to Jan 9, 2017 FDA reported in a FDA Safety Communication on “Cybersecurity Vulnerabilities Identified in St. Jude Medical’s Implantable Cardiac Devices and Merlin@home Transmitter.

At risk:

  • Patients with a radio frequency (RF)-enabled St. Jude Medical implantable cardiac device and corresponding Merlin@home Transmitter
  • Caregivers of patients with an RF-enabled St. Jude Medical implantable cardiac device and corresponding Merlin@home Transmitter
  • Cardiologists, electrophysiologists, cardiothoracic surgeons, and primary care physicians treating patients with heart failure or heart rhythm problems using an RF-enabled St. Jude Medical implantable cardiac device and corresponding Merlin@home Transmitter

I’ve been talking to our medical device customers about mobile security of implanted devices for over 4 years now.

I  gave a talk on mobile medical device security at the Logtel Mobile security conference in Herzliya in 2012 ago and discussed proof of concept attacks on implanted cardiac devices with mobile connectivity.

But – ICD are the edge, the corner case of mobile medical devices.  If a typical family of 2 parents and 3 children have 5 mobile devices, it is a reasonable scenario that this number will double withe devices for fetal monitoring, remote diagnosis of children, home-based urine testing and more.

Mobile medical devices are becoming a pervasive part of the Internet of things; a space of  devices that already outnumber workstations on the Internet by about five to one, representing a $900 billion market that’s growing twice as fast as the PC market.

There are 3 dimensions to medical device security – regulatory (FDA), political (Congress) and cyber (vendors implementing the right cyber security countermeasures)

The FDA is taking a tailored, risk-based approach that focuses on the small subset of mobile apps that meet the regulatory definition of “device” and that:

  • are intended to be used as an accessory to a regulated medical device, or
  • transform a mobile platform into a regulated medical device.

Mobile apps span a wide range of health functions. While many mobile apps carry minimal risk, those that can pose a greater risk to patients will require FDA review. The FDA guidance document  provides examples of how the FDA might regulate certain moderate-risk (Class II) and high-risk (Class III) mobile medical apps. The guidance also provides examples of mobile apps that are not medical devices, mobile apps that the FDA intends to exercise enforcement discretion and mobile medical apps that the FDA will regulate in Appendix A, Appendix B and Appendix C.

Mobile and medical and regulatory is a pretty sexy area and I’m not surprised that politicians are picking up on the issues. After all, there was an episode of CSI New York  that used the concept of an EMP to kill a person with an ICD, although I imagine that a radio exploit of  an ICD or embedded insulin pump might be hard to identify unless the device itself was logging external commands.

Congress is I believe, more concerned about the regulatory issues than the patient safety and security issues:

Representatives Anna Eshoo (D-CA) and Ed Markey (D-MA), both members of the House Energy and Commerce Committee sent a letter last August asking the GAO to Study Safety, Reliability of Wireless Healthcare Tech and report on the extent to which FCC is:

  • Identifying the challenges and risks posed by the proliferation of medical implants and other devices that make use of broadband and wireless technology.
  • Taking steps to improve the efficiency of the regulatory processes applicable to broadband and wireless enabled medical devices.
  • Ensuring wireless enabled medical devices will not cause harmful interference to other equipment.
  • Overseeing such devices to ensure they are safe, reliable, and secure.Coordinating its activities with the Food and Drug Administration.

At  Black Hat August 2011, researcher Jay Radcliffe, who is also a diabetic, reported how he used his own equipment to show how attackers could compromise instructions to wireless insulin pumps.

Radcliffe found that his monitor had no verification of the remote signal. Worse, the pump broadcasts its unique ID so he was able to send the device a command that put it into SUSPEND mode (a DoS attack). That meant Radcliffe could overwrite the device configurations to inject more insulin. With insulin, you cannot remove it from the body (unless he drinks a sugary food).

The FDA position that it is sufficient for them to warn medical device makers that they are responsible for updating equipment after it’s sold and the downplaying of  the threat by industry groups like The Advanced Medical Technology Association is not constructive.

Following the proof of concept attack on ICDs by Daniel Halperin from the University of Washington, Kevin Fu from U. Mass Amherst et al “Pacemakers and Implantable Cardiac Defibrillators:Software Radio Attacks and Zero-Power Defenses”  this is a strident wakeup call to medical device vendors  to  implement more robust protocols  and tighten up software security of their devices.

Tell your friends and colleagues about us. Thanks!
Share this

Apps vs. the Web, enemy or friend?

Saw this item on Gigaom.

George Colony, the chairman and CEO of Forrester Research, re-ignited a minor firestorm recently, with a presentation at the LeWeb conference in which he argued that the web is dead, and being replaced by the app economy — with mobile and smartphone apps that leverage the cloud or other services rather than the open web.

I have written here and here about the close correlation between Web application security and Web performance.

I know that Mr. Colony has sparked some strong sentiment in the community, in particular from Dave Winer:

If I can’t link in and out of your world, it’s not even close to a replacement for the web. It would be as silly as saying that you don’t need oceans because you have a bathtub. How nice your bathtub is. Try building a continent around it.

Of course, that is neither true nor relevant.

Many apps are indeed well connected, and the apps that are not wired-in, don’t have to be wired; the app is simply doing something useful for the individual consumer (like iAnnotate displaying a PDF file of music on a iPad or Android tablet).

iAnnotate turns your iPad into a world-class productivity tool for reading, annotating, organizing, and sending PDF files. Join the 100,000s of users who turn to iAnnotate for their PDF annotating needs. We designed iAnnotate to suit your individual workflow.

I became even more cognizant that apps may overtake the open Web over the past 2 weeks when Google Apps was going through some rough spots and it was almost impossible to read email to  software.co.il or access or calendars…except from our Android tablets and Nexus S smartphones.   Chrome and Google Apps was almost useless but Android devices just chugged on.

There is a good reason why apps are overtaking the open browser-based web.

They are simply more accessible, easier to use and faster.

This is no surprise as I noted last year:

The current rich Web 2.0 application development and execution model is broken.

Consider that a Web 2.0 application has to serve browsers and smart phones. It’s based on a heterogeneous server stack with 5-7 layers (database, database connectors, middleware, scripting languages like PHP, Java and C#, application servers, web servers, caching servers and proxy servers.  On the client-side there is an additional  heterogeneous stack of HTML, XML, Javascript, CSS and Flash.

On the server-side, we have

  • 2-5 languages (PHP, SQL, tcsh, Java, C/C++, PL/SQL)
  • Lots of interface methods (hidden fields, query strings, JSON)
  • Server-side database management (MySQL, MS SQL Server, Oracle, PostgreSQL)

On the client side, we have

  • 2-5 languages ((Javascript, XML, HTML, CSS, Java, ActionScript)
  • Lots of interface methods (hidden fields, query strings, JSON)
  • Local data storage – often duplicating session and application data stored on the server data tier.

A minimum of 2 languages on the server side (PHP, SQL) and 3 on the client side (Javascript, HTML, CSS) turns developers into frequent searchers for answers on the Internet (many of which are incorrect)  driving up the frequency of software defects relative to a single language development platform where the development team has a better chance of attaining maturity and proficiency. More bugs means more security vulnerabilities.

More bugs in this complex, broken execution stack means more things will go wrong and as devices and apps are almost universally accessible now; it means that customers like you and me will not tolerate 2 weeks of downtime from a Web 2.0 service provider.  If we have the alternative to use an app on a tablet  device, we will take that alternative and not look back.

Tell your friends and colleagues about us. Thanks!
Share this

Mobile device security challenges

It has been said that there is nothing new under the sun and that every generation forgets or never learned the hard-earned lessons from the spilled blood of the previous generation.

Reviewing the security and compliance issues  of a new mobile medical device recently, I was struck by how familiar many of the themes are.

What makes mobile devices special? Actually nothing.

Deploying line of business or life science applications on mobile Android tablets or an iPad has a different set of security requirements than backing up your address book. It requires thinking about the software security and privacy vulnerabilities in a systematic way and using a rigorous practical threat analysis methodology. As we will show in this short article, the key vulnerabilities of mobile devices are similar to traditional IT security vulnerabilities even if the threat surface is dramatically different.

However, a software security assessment of a life science software application deployed on a mobile device needs to look beyond the malware and spyware and data breach attacks on the device. Mobile Android tablets or iPads running electronic medical records applications are usually deployed in uncontrolled, complex and highly vulnerable environments such as enterprise IT networks in hospitals.  The software security issues are much more severe than those of a single tablet:   a combination of network vulnerabilities, application software vulnerabilities, malicious attackers superimposed on  the large, complex threat surface of an enterprise IT network.

The mobile medical device is now an attack vector into the hospital network, a far more valuable asset than the mobile device itself.

It seems that there are 5 key areas of vulnerability for  mobile devices, but not surprising, they all coincide with the classic IT network vulnerabilities:

Protocol coverage is lacking: Mobile  devices often rely on built-in  firewalls or enterprise network isolation. The protection that firewalls provide is only as good as the policy they are configured to implement and there are a whole slew of issues related to remote security policy management of untethered devices. I expect that analysis of network exploits on mobile devices with internal firewalls, will match analysis of real-world configuration data from corporate firewalls  that shows  rule sets that frequently violate well-established security guidelines (for example zone-spanning objects and lack of stealth rules). In addition, a stateful inspection firewall on a mobile device doesn’t perform deep content inspection on complete sessions and is therefore blind  to data theft attacks – for example piggy-back attacks  on text messaging in order to steal sensitive data.

Proxy-based access to control a device is convenient but may enable attackers to compromise a device and steal data – proxies end-point devices to obtain direct access to the Internet – research with clients show us that as much as 20 percent of all endpoints already bypass content filtering proxies on the enterprise IT network.

Visibility of network transactions is usually missing making incident response very difficult: Firewall and proxy logs are generally never analyzed, and often lag hours behind an event. An IPS often relies on anomaly detection. Anomaly detection relies on network flow data, which is often reported at intervals of 15 to 45 minutes. With that kind of lag, an entire network can be brought down. Because anomaly detection is looking for an anomalous event rather than an attack, it is frequently plagued by time-consuming false positives. A proxy on the other hand relies on URL filtering and simple keyword matching that analyzes the HTTP header and URL string. By looking at content and ignoring the network; a proxy can suffer from high rates of false negatives, missing attacks.

Multiple security and application layers increases cost of implementation and maintenance. Installation of multiple, disparate, proxy-based security products complicate network and end-point maintenance. Proxies require changes to the network infrastructure and in large networks may be impossible to install.  Updating mobile device application software to latest patch levels can be challenging to enforce and control and may result in injecting new software vulnerabilities into the device as there is probably not central IT administrator in charge of updating the mobile electronic medical records application running on 300 Android tablets in the hospital.

Redundant, multiple network security elements increase risk in the overall solution: This is additional risk that manifests itself as a result of the interaction between  mobile devices accessing cloud services via  a complex system of cache servers, SSL accelerators, Load balancers, Reverse proxy servers, transparent proxies, IDS/IPS and Web Application Firewalls. Consider that endpoints can bypass SSL proxies by specifying a gateway IP address and transparent proxies on a Windows network are no assurance for unauthenticated user agents bypassing the entire proxy infrastructure. HTTP-Aware firewalls such as Web application firewalls can be completely or partially bypassed in some cases. Transparent proxies can be compromised by techniques of HTTP response splitting since they rely on fine-grained mechanisms of matching strings in HTTP headers.  This is why Mozilla is delaying their implementation of Web sockets which may not matter if you’re running Chrome OS.

It’s a new dawn but with old rules.

Tell your friends and colleagues about us. Thanks!
Share this

Japanese mobile carrier Willcom on the skids

I was in Moscow this week and was pretty disappointed with the Beeline WiMax offering – which basically didn’t work in the area where we were staying (not far from Mendeleevska Metro station)

WiMax is not there yet and mobile data is still shaking out. According  my buddy  Todd Walzer (Todd lives in Tokyo and is a managing partner in www.iland6.com Capital and Development Co., Ltd).

Japan’s phone carriers have been managing this recession pretty well. NTT even recovered the #1 position in corporate profits from Toyota Motors.

However the 4th largest mobile carrier – Willcom – is in deep trouble.

Willcom entered the Japanese equivalent of Chapter 11, and the company is being  restructured under legal supervision.


Willcom started in 1990, and has operated a PHS (Personal Handiphone Service) network.  Thanks to cost advantage of this “half-duplex” technology, Willcom could keep a 5% share of Japan’s 100 million subscriber mobile voice market until 2 years ago. It was a pioneer of wireless data services, and an early leader in that market.


But PHS remained a niche technology adopted marginally in Japan and China, while Willcom’s competitors DoCoMo, AU and Softbank adopted CDMA with economies-of-manufacture from worldwide deployment.  Meanwhile, newcomer EMobile leapfrogged Willcom’s data rates with an HSDPA service.


In 2007-8, Japan’s Ministry of Communications made two “Broadband Mobile” licenses available, and Willcom applied proposing a “Next Generation PHS” network. The ministry favored this “Made-in-Japan” technology and awarded Willcom a license. But Willcom has struggled to bring off development of a platform with few prospective users worldwide.  It buckled under the $Billion+ development cost, on top of its existing $Billion+ debt.

Meanwhile the other licensee UQC (a consortium led by KDDI) deployed its WiMAX service on schedule.

Tell your friends and colleagues about us. Thanks!
Share this