Hacking the Medical Industry
by lg0p89
It seems as though hospitals and local governments are targeted more than other industries.
With the criticality of the services and access to data, this is no wonder. Within the hospital industry, a frequent target is the Electronic Health Records (EHR). The hospital, nurses, and doctors all depend on this for patient care every single day. Without these, the medical staffing is not able to dispense medications, apply treatments, and perform other aspects of medical care. There should be backups, which are regularly checked, in place. This alleviates much of the issue unless these also have been successfully compromised.
Any downtime here is a problem.
A hospital in Ohio found out how much of a disaster this tends to be, especially over a six day period of having their EHR inaccessible. Southern Ohio Medical Center (SOMC) is located in Portsmouth, Ohio. The facility is reasonably sized for the community with 248 beds. The facility provides primarily emergency and surgical care, as well as other health care services.
November 11, 2021 proved to be an interesting day.
SOMC posted disturbing news on Facebook that it had been compromised. In essence, a third-party had gained access to the facility's servers. This had occurred in the early hours of the day. As a result of this, they had been working with law enforcement and a cybersecurity firm. The good news is it appears they caught this relatively early into the compromise. Too many times, a breach is not detected for weeks or months. At least the timing mitigated the opportunity for the attackers to have a full reign of their network for an extended period. At this point though, no details have been shared regarding the scope of the compromise, method used, attack surface breached, or other details.
We do know the effects of this.
The facility initially was forced to cancel appointments and divert ambulances to other medical facilities. Later, on November 17th, they were forced to cancel the outpatient medical imaging, outpatient cardiac testing, sleep laboratory, outpatient rehabilitation, and pulmonary function testing, along with anti-arrhythmic clinic appointments and work. With this much of an issue, patient safety and care were clearly affected.
Why Haven't We Seen More Malware on Medical Devices?
As we continue to read about the attacks on hospitals, medical clinics, and doctor's offices, one question comes to mind: Why haven't the medical devices been targeted? Hospitals require their systems to be operable 24/7. The operating room or emergency room operations would be excessively difficult without their enterprise systems running. This isn't just email, but their EHR, Electronic Medical Records (EMR), billing, and everything else involved with treating patients.
The critical nature of these systems is one aspect driving the attacks.
Without these, work flow grinds to nearly a halt with only the essential surgeries and treatments being done. Several hospitals successfully attacked have had to postpone surgeries and reschedule appointments. This has proven to be a nightmare for the hospital's admin teams. Imagine the fun and pure enjoyment of getting the "We've been compromised and our systems are encrypted" call on Friday at 3 p.m.
Even more critical would be an attack on the medical devices themselves.
Granted, not having access to your systems is terrible enough, but having access and not knowing for sure which are compromised, which aren't, and if the instruments are providing accurate data (e.g., blood type, correct test results, and blood pressure).
The medical devices are not immune from the potential attack.
These are IoT devices connected to the network using Bluetooth, BLE, Wi-Fi, and attached to the network with a cable or a combination of these. The networks have been compromised time and again. Gaining access to the devices is merely the next step.
This is not an academic rant or mental gymnastics.
There have been incidents with infusion pumps being attacked. These instances are only a very small fraction of the attacks. One estimate from 2018 noted infusion pump security alerts were at two percent. Other targets include imaging devices. These likewise are not impervious to attacks.
In 2017, staff at two hospitals in the United States detected WannaCry on their MRI LCDs. The "uh-oh" moment was when they saw the ransomware screen demanding payment to unlock the devices. This also happened in the United Kingdom in 2017, when 1200 diagnostic devices had to be taken offline after being infected with WannaCry. This set of attacks was worse than the U.S. version, in that at least 81 of the 231 National Health Service's hospitals, 603 primary care, and 595 medical facilities were infected.
There are a few points to consider when analyzing what makes these so susceptible to potential attacks.
Too much of the equipment in use are legacy systems. These can be, based on the medical facility, over a decade old. These may be used until they completely break down and then are used for parts. There are IT admins who search for these systems on eBay for spare parts and gladly purchase them. These are used for so long because they simply work, and the replacements are expensive. For a hospital or clinic on a budget, this is how they can operate.
The medical facility will hopefully have a pen-test done annually.
The focus for the pen-test would be the enterprise and IT infrastructure. The perimeter and test points would require the most amount of time traditionally. The hospital may not view the devices, so this would be expected. The staffing for the pen-test through a third-party may not be completely comfortable providing an opinion of device security. This leaves a rather significant hole for the attackers to use.
The new devices being put into use are using newer technology (e.g., BLE) in new applications.
The engineers may not have worked through or mitigated a full-threat model for these devices. Reworking them when a vulnerability is noted takes time and money. With these factors, all of the new technology's attributes may not have been considered.
These devices are available to be targeted.
They haven't yet as there isn't a glaring need to.
The pool for medical facility targets is still open, as we can see in all of the news stories of compromises, Personal Identifiable Information (PII) being exfiltrated, and all the other data open for sale. Once this avenue begins to dry up due to defensive improvements, the attackers will need to find other targets. As they already have the expertise in the medical field, there is only one place to look: the devices and equipment used directly with the patients to diagnose, sustain, and save lives.
Why Aren't There Medical Device Honeypots?
The Blue Team and defensive security are not new concepts by any stretch of the imagination.
As soon as the first attack was detected so many years ago, there was the research on how the attack was accomplished, and what to change and update so the issue would not occur again. Over the years, there have been many tools to help with this endeavor.
One of the tools in use - more so in prior years - has been the honeypot.
The early years of security are nebulous and tend to be documented only at a high-level and for highly visible exploits. Perhaps this is a good thing, adding to the intrigue of our industry. One of the earliest examples occurred in 1986 with Clifford Stoll, an U.C. Berkeley admin, who noted a $0.75 accounting error in the computer usage accounts. He tried extensively but could not track the origin for this. To create this monitoring network, he used two methods (monitoring all 50 phone lines into the system and creating a fake set of files for the "Star Wars" missile defense system). You can read all about it in The Cuckoo's Egg.
This tool, whose root function hasn't changed much since its creation, is used to distract the attackers from the actual files and systems. As a decoy, these appear to the attacker as a legitimate system with a few vulnerabilities. I note there should be vulnerable aspects as if the system is engineered with too much security requiring months of undetected attacks, or the attackers may move onto another attack point in the network.
The function of the honeypot is to lure them in, have them spend their resources (time, effort, and hardware) for as long as you are comfortable with them being there, while you monitor and gather information on them before shutting them down. In the case where it becomes clear quickly there is no way in, the attacker, having done a break-even analysis, would move onto other targets in your network. If not properly configured, they may pivot from the honeypot to viable production systems.
Monitoring their activity deserves more explanation.
With this step, the organization has the opportunity to watch and learn from the active attack. This industry certainly is not static. Over time, the methods of attack have changed. This provides the opportunity to record the steps, methods, and potentially tools used for the attack. If this sample, when compared to the others, is the same or marginally the same, the monitoring did not add to the body of knowledge. If there are new methods used, then our industry can learn from this and apply updated defenses to mitigate this form of attack. The defense improvement should make compromising the system harder for the next iteration.
In general, enterprise honeypot sourcing is not an issue.
There are ample open-source and commercial options available. You can use the open-source option and customize this as much as you wish or purchase the commercial version and pay for all the bells and whistles. For the adventurous, you can also code your own. With these, there are ample configurations to meet your needs. You can set this up to look exactly like your network, which is the point.
While this has a tendency to work on certain levels, the honeypot designed specifically for medical devices is lacking. While recently surveying the honeypot samples, there was not a suitable honeypot with a medical device orientation. There were honeypots for printers, SSH, and just about everything else you could think of.
For other IoT devices, there are a few options available.
These are not a perfect fit for the medical device simulation. You may attempt to mold these to the medical device format,but the process would be awkward and only approximate the medical devices. This would be like jamming a round dowel to a square hole. This again brings forth the issue of what happens when the attacker realizes this is a fake.
To create these to mimic a medical device would only take time and effort.
The firm would need to research each type and its fingerprint to best create the honeypot to simulate the target. This would include the configuration, naming format, logs, and it would be great to include data flows copying the actual device's activity. This is not a complex set of tasks, but does require access to the particular device. The architect would need access to these in order to create the image and activity to mimic with the medical device honeypot.
As time is money (or is it money is time), the concern is the revenue potential and break-even point.
Not to be too accounting-oriented, but this is a consideration. If this endeavor would require hundreds of hours, it may not be the optimal use of time. This is presently a completely viable market with these devices spread throughout the world. These devices also vary widely in application and function. Each medical facility may have infusion pumps, insulin pumps, heart monitors, and many other forms. To say the market for these is huge would be a vast understatement.
The persons and organizations behind the attacks will continue to grow and attack targets with greater frequency.
As this happens, our industry will continue to improve detection and defensive measures. As this occurs, the attackers will find other targets. The natural extension is the pivot to medical devices.
To prepare, the cybersecurity industry should start to address this.