As a patient, do you ever consider the impact software quality has on your health? No? Well, you probably should.
Each year we see more medical devices on the market that connect to wireless networks. Patients use these devices for everything from combating sleep apnea to regulating heart beats to keeping track of prescriptions. These connected devices communicate with a medical host to transmit patient data or information about the device, perform updates, ensure proper operation and many other tasks.
The problem is, as these devices become increasingly connected, the potential for cyber criminals to inflict real life, physical damage also increases, depending on the quality of the software that runs on those devices. And depending upon what the connection is used for, a disruption in connectivity has the potential to put lives at risk.
During the recent New York City Healthcare Security Summit, Medical Device Innovation, Safety and Security Consortium Executive Director, Dr. Dale Nordenberg, told Healthcare Info Security that, “We estimate that over the next 10 years we will see over 500 billion exposures between a person and a connected mobile device.”
When you combine the rise in cybercrime with this knowledge, the doomsday-type scenarios that result seem like something that should be relegated to a bad action movie. In their worst nightmares, the inventors of medical devices could have envisioned someone hacking into a medical network and cause disruption to the devices connected to them.
The sad reality of it, though, is that in modern society, hackers need no reason to ply their dastardly deeds beyond, “I’m bored, what can I mess with?” It almost stands to reason – no matter how morbid that reasoning may be – that, when developing current generations of pacemakers, scientists need to consider how they can be hacked.
Surprisingly, Dr. Nordenberg said that in 2017, the push to combat this potential disaster found an odd and unwitting ally.
“We’re at least a year ahead of where I thought we’d be because of WannaCry,” said Dr. Nordenberg in reference to the ransomware attach that affected, among other organizations, Britain’s National Health Service.
Still, it should not take an actual data breach or denial of service attack to spark efforts to combat the potential for medical device disruption. Obviously, the medical community needs to tackle software quality, address the way medical devices are configured and address any existing software quality or security vulnerabilities.
“If we work hard to collect data, we will know how to design better devices,” said Dr. Nordenberg. “We will know how to configure the devices we have better, and the hospitals will know better how to configure and optimize their networks so they’re a better and safer environment for the medical devices we need.”
Nordenberg also points out that this process will not be a quick one, and he is correct. The first problem the medical community has to tackle is the sheer volume of code that goes into the software running on medical devices, and legacy code in particular.
When you consider that medical device technology cannot be reinvented every time a new version is built or an improvement added, you realize that legacy software abounds in medical devices. This means application code that may or may not have been vulnerable to breach years or even decades ago may now represent a weak link in the device and now needs to be reconfigured to eliminate vulnerabilities.
Manual analysis of that much code is simply impossible. That kind of effort will require automated code review of software running on medical devices. Automated analysis can provide an efficient and accurate means for identifying issues with embedded legacy applications, while ensuring that any new code added to the software does not introduce new potential breach points.If automated analysis of medical device software saves even one life, such a requirement would be worth going beyond the “least burdensome approach” because in the medical industry, software quality is a life and death issue.