When I ask the question of Healthcare CIOs and CISOs "What keeps you up at night?" one of the most common answers I receive -after the usual jokes about indigestion, or the snoring spouse, is the problem of what to do about securing medical devices in our hospitals. Most healthcare executives are acutely aware of the problem (to some degree at least), but very few have an effective or scalable solution at hand to address this ever-growing risk.

[This is a two-part story. The first part can be read here.]

I recently met with the CIO and CISO of a large US healthcare system to chat about how the system was going about securing its 350,000 network attached medical devices. They were busy assessing and profiling all of the disparate devices from a multitude of different vendors that the pre-merger, independent hospitals had purchased over the past twenty years or so. The Health System had multiple teams of third party vendors from many of the big names in bio-engineering, working with its own IT team to review configurations, firmware and OS/ application versions, and to make updates where necessary in order to improve the security posture of these devices.

The CIO however was greatly concerned by the number and churn in these endpoints -given warranty replacement units and new devices arriving at hospitals seemingly on a weekly basis. He was concerned whether they would ever be able to get in front of their hardening project, and whether reconfiguration and lock-down would ever really secure these network attached systems at the end of the day.

After listening carefully to his plan and all the activities he and his CISO had sanctioned, I suggested cautiously, that perhaps the health system was on the wrong path. My argument was that they would never be able to keep up with and manage 350,000 disparate biomedical devices, growing by twenty percent per annum, using a strategy essentially designed to manage PCs and workstations. One where domain level tools could be used to patch and configure the vast majority of endpoints. The manpower requirements alone I suggested, would consume his entire IT team's bandwidth and budget at some point, if not very soon.

I suggested that he abandon entirely all thoughts of securing individual endpoints by locally hardening devices, and by disabling services like TFTP, FTP, TelNet and SSH, that many of his medical devices had left the factory with enabled, and instead look at other control points to secure those devices (compensating security controls) that would enable much higher levels of automation, and reduce the margin for human error that a manual process would inevitably lead to.

I suggested that he use his network as the control point rather than attempt to manage so many individual endpoints. By enabling TrustSec -a built-in access system in his newer Cisco switches and routers, he could lock down each endpoint device whether wired or wirelessly attached to the network, and control in a uniformed manner exactly which ports and protocols each device could communicate on, which users could administer each device, and which other devices each medical device could communicate with, i.e. specifically authorized canister, gateway or clinical information systems only.... and nothing else!

By employing ISE (Cisco Identity Services Engine) to set access policy, which would then be enforced by TrustSec, (something that was already being used to manage guest wireless access), the health system could create uniform enterprise policy implementation across all sites and locations, and avoid the need for possibly hundreds of firewall engineers to write and update access control lists in switches, routers, and firewalls. What's more, rules written in ISE could be written in easy-to-understand business language, rather than complex access control syntax for direct entry into infrastructure devices by firewall and network engineers.

Furthermore ISE could be used to survey and profile each of model of medical device, such that a profile could be developed and assigned once for each model, and applied globally across the entire enterprise of 350,000+ medical devices, thus automating security for the almost un-securable!

I continued, "What's more, the same profile you assign to a medical device in one hospital, is used for a similar device in another hospital so long as its all part of the same ISE domain. Thus you can more effectively manage your medical device asset inventory across hospitals, by quickly assigning medical devices when and where needed rather than to tie up money in potentially hundreds of unused assets in each location."

"In other words" I explained, "Using ISE and TrustSec, you can provide your users with dynamic segmentation capabilities such that you can take a medical device (or truck load of medical devices) from one site to another site in need of those devices, (for perhaps local disaster management), and have those devices immediately recognized by the network and assigned the right access permissions as soon as they are plugged in or otherwise connected to the network. No need to engage a firewall or network engineer to add MAC addresses to an ACL (access control list) at 2am in the morning -just plug it in and it will work!"

Essentially you will have an enterprise-wide dynamic automated user and device access system, that is enterprise policy-driven in easy to understand language (versus firewall and switch syntax), that will actually save your biomed team money because they can run a minimal asset inventory across the entire health system. What's more, in so doing, you are actually securing the un-securable and protecting medical devices from attack, as well as protecting the main hospital business network from being attacked from an easily compromised medical device.

A large number of leading US healthcare delivery organizations are already using ISE and TrustSec to secure their medical devices, research and intellectual property, PHI, PII and other confidential information, by security segmentation of their networks and IT systems. Many are working towards micro-segmentation at the individual device level. Many more are using the same segmentation approach and technology to isolate their PCI payment systems, their guest and contractor network access, and for network access quarantine to perform posture assessments on laptops and mobile devices re-attaching to the network after being used to treat patients in the community.

For more information on this approach, read Cisco's Segmentation Framework and the Software-Defined Segmentation Design Guide.

For information about how Cisco's Security Advisory Services can to assist you to design secure segmentation in your environment, please review Cisco's Security Segmentation Service or contact your Cisco sales team.