Arlie Hartman: Pushing the Boulder of Medical Device Security Up the Hill

Greek mythology tells the tale of Sisyphus, king of Ephyra–a ruthless, cunning leader who often got the best of the Greek gods. Zeus punished Sisyphus for his hubris with the insidious task of eternally pushing a boulder up a hill, but never allowing him to get it to the top. Often, we are told that medical device security management is a Sisyphean task, and, as I discovered, for good reason.

Recently, I spent a significant amount of time working on a medical device at a women’s health center. I completed a risk assessment, contacted the OEM to gather the patch table and antivirus statement and created the change management documentation to implement the security controls. The device was patched and had antivirus software installed that would be monitored by the local IT department. I then proceeded to work on other devices within the health system. I continued to push the boulder.

Several months later, I received a phone call from the women’s health center director and a representative of the clinical engineering department. They requested help with malware on the same device on which I had implemented security controls. After receiving complaints of failed transmission of studies to the picture archiving and communication system, clinical engineering had downloaded, installed, and executed a noncommercial malware scanner. The staff misinterpreted the scanner finding as malware and contacted the OEM. At this point, I feel the boulder slipping.

I worked with the IT department and clinicians to schedule a downtime window to perform a complete hard-drive scan with the installed antivirus software. After the window expiration, the antivirus administrator informed me the medical device had not checked in and the scan had not been completed. After several phone calls, e-mails and a site visit, I discovered the OEM had re-imaged the device to its baseline configuration of an operating system with a previous service pack level and placed the device back on the network with no antivirus installed.

To add insult to injury, the device was really infected with malware. After scanning and removing the malware — for the second time — I made a few tweaks to the change management documentation and submitted it for approval. Back to square one. The boulder had rolled over me, hit bottom.

How do we prevent this from happening? Change management cannot live in a vacuum any more than medical devices cannot be connected to the network. Change management’s objective is to ensure changes are handled efficiently and promptly through standardized methods and procedures. To that end, changes are approved by management and implemented with a minimized and accepted risk, resulting in a new status and adding value to the enterprise.

While I had e-mailed my change documents to clinical engineering, I also needed to send it to IT and the clinicians. I had received approval from the clinicians but should have attained approval from a change advisory board (CAB) made up of IT, clinical engineering and clinical management. When the OEM came onsite, any of its changes should have been an emergency change; schedules could have been made to ensure proper patching and security controls could be implemented. The most important lesson is we should all have been talking together instead of to each other.

While we push the boulder up the hill, it is OK for it to slip at times. Just don’t let it roll over you on the way down.

Arlie Hartman

Systems Security Specialist



Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s