As you navigate today's modern surgical rooms and recovery wards you'll be confronted with a vast array of life-saving and life-monitoring equipment – many of which are connected either wirelessly or physically to the buildings local area network. Lying at the heart of each piece of medical equipment, allowing them to communicate status and alerts to other networked monitoring stations, a menagerie of embedded operating systems can be found.
Closer inspection of the equipment will yield an astoundingly diverse array of manufacturer names. While a typical office environment may produce a list of 10-20 brand-name equipment manufacturers and an industrial plant may encompass 50-100 manufacturers, health care environments play host to the widest assortment of manufacturer's products – in fact you might say that just about any device, if it looks slightly different to any other, has probably come from a yet another manufacturer.
Therein lays a major problem. While most ‘smart' health care equipment uses common embedded operating systems, it is impossible to update or patch them as if they were regular computing devices. Just because the portable defibrillator and the maternity wards ultrasound machine are using Microsoft Windows 95 for their embedded operating system, it doesn't mean that the same strategy can be taken in applying missing security patches (even after assuming that an old operating system is still supported by the vendor, and you can discover where you need to insert the physical update media).
Then, even if you have the capability to add any necessary OS security patches, doing so may leave the health care operator exposed to legal and financial liabilities. In many cases, unless the patch has been fully tested with that particular piece of equipment and “approved” by the manufacturer, application of the patch (or any other software change) will likely void any warranties on the equipment and invalidate any applicable insurance coverage to the health care provider. Which, in today's world, could result in an extremely costly experience for the organization should the equipment happen to fail when a patient requires it.
Heath care operators are aware of this problem and have been working extensively with their suppliers to overcome this hurdle. However, the fact remains that there are often substantial delays between an OS vendor's patch release and the time before the equipment manufacturer is able to release an “approved,” tested, update. In too many cases, this delta may be measured in months -- and then comes the logistical problem of physically visiting each unique machine and applying the necessary update in a timely manner.
From a network threat perspective, while the numbers of malicious worm outbreaks have decreased substantially in recent years, the probability of host compromise has not. Less than half a decade ago, the looming threat within health care was the prospect of network worms effectively conducting a denial of service – thereby preventing the use of life saving equipment.
Today's profit-motivated attackers tend to be more stealthy with their malware, and are constantly exploring new ways to make money. Machines using embedded operating systems based upon the popular Windows and Linux formats are the most vulnerable (and valuable) to them. By exploiting known and unpatched vulnerabilities within these operating systems, it is unlikely that the attacker will initially know what the actual device is because, for all intents and purposes, it's just another host on the network. Consequently there is a high risk of machine failure because of unfortunate “tinkering,” while the infected equipment participates in some botnet functionality, such as acting as a spam relay or an anonymizing proxy.
Looking forward, we can expect the problem to grow and become increasingly more difficult to manage. As older generations of non-networked health care machines get replaced with ‘smarter' network-integrated versions, the proliferation of embedded operating systems will grow. While the heathcare industry is not alone in this regard, and all vertical sectors will have to address the problems with aging and unsupported embedded operating systems, their diverse ensemble of networked equipment will require the greatest attention.
The solution ideally lies with the equipment manufacturers and their promptness in validating and supporting the embedded operating systems of their products.
Independently, heath care organizations can take a few steps of their own in mitigating some of the risks. Regular vulnerability scanning and OS-level monitoring will help identify vulnerable devices and allow the organization to track the speed of manufacturers' update responses, while classic network-based network intrusion prevention technologies will mitigate the prospect of worm propagation and vulnerability-based exploitation. Anomaly detection systems can also play a role in understanding if new threats are propagating the network and having adverse effects on device stability – however, it is not a preemptive technology and requires a higher-level of back-office technical support.
Closer inspection of the equipment will yield an astoundingly diverse array of manufacturer names. While a typical office environment may produce a list of 10-20 brand-name equipment manufacturers and an industrial plant may encompass 50-100 manufacturers, health care environments play host to the widest assortment of manufacturer's products – in fact you might say that just about any device, if it looks slightly different to any other, has probably come from a yet another manufacturer.
Therein lays a major problem. While most ‘smart' health care equipment uses common embedded operating systems, it is impossible to update or patch them as if they were regular computing devices. Just because the portable defibrillator and the maternity wards ultrasound machine are using Microsoft Windows 95 for their embedded operating system, it doesn't mean that the same strategy can be taken in applying missing security patches (even after assuming that an old operating system is still supported by the vendor, and you can discover where you need to insert the physical update media).
Then, even if you have the capability to add any necessary OS security patches, doing so may leave the health care operator exposed to legal and financial liabilities. In many cases, unless the patch has been fully tested with that particular piece of equipment and “approved” by the manufacturer, application of the patch (or any other software change) will likely void any warranties on the equipment and invalidate any applicable insurance coverage to the health care provider. Which, in today's world, could result in an extremely costly experience for the organization should the equipment happen to fail when a patient requires it.
Heath care operators are aware of this problem and have been working extensively with their suppliers to overcome this hurdle. However, the fact remains that there are often substantial delays between an OS vendor's patch release and the time before the equipment manufacturer is able to release an “approved,” tested, update. In too many cases, this delta may be measured in months -- and then comes the logistical problem of physically visiting each unique machine and applying the necessary update in a timely manner.
From a network threat perspective, while the numbers of malicious worm outbreaks have decreased substantially in recent years, the probability of host compromise has not. Less than half a decade ago, the looming threat within health care was the prospect of network worms effectively conducting a denial of service – thereby preventing the use of life saving equipment.
Today's profit-motivated attackers tend to be more stealthy with their malware, and are constantly exploring new ways to make money. Machines using embedded operating systems based upon the popular Windows and Linux formats are the most vulnerable (and valuable) to them. By exploiting known and unpatched vulnerabilities within these operating systems, it is unlikely that the attacker will initially know what the actual device is because, for all intents and purposes, it's just another host on the network. Consequently there is a high risk of machine failure because of unfortunate “tinkering,” while the infected equipment participates in some botnet functionality, such as acting as a spam relay or an anonymizing proxy.
Looking forward, we can expect the problem to grow and become increasingly more difficult to manage. As older generations of non-networked health care machines get replaced with ‘smarter' network-integrated versions, the proliferation of embedded operating systems will grow. While the heathcare industry is not alone in this regard, and all vertical sectors will have to address the problems with aging and unsupported embedded operating systems, their diverse ensemble of networked equipment will require the greatest attention.
The solution ideally lies with the equipment manufacturers and their promptness in validating and supporting the embedded operating systems of their products.
Independently, heath care organizations can take a few steps of their own in mitigating some of the risks. Regular vulnerability scanning and OS-level monitoring will help identify vulnerable devices and allow the organization to track the speed of manufacturers' update responses, while classic network-based network intrusion prevention technologies will mitigate the prospect of worm propagation and vulnerability-based exploitation. Anomaly detection systems can also play a role in understanding if new threats are propagating the network and having adverse effects on device stability – however, it is not a preemptive technology and requires a higher-level of back-office technical support.
