Standards Watch | User Beware: Virus Checkers on PACS Workstations

It was about a year ago that I did not receive a reply to an e-mail for several days from a PAC system administrator at a major institution in Houston. After three days, I called her and asked whether there might be a problem - finding out that the e-mail system had been down for three days, hopefully to be back up in another day or so. It was on the bottom priority of the IT staff, which was focusing on getting all clinical systems back up, after being infected with a virus. Just the Web distribution system for imaging was down for a whole day.

I heard a similar story from a vendor's representative, who spent a whole day after a virus struck at a Boston healthcare institution that basically wiped out all the DR systems, not allowing any routine x-rays for a day. Viruses, worms, or whatever malicious software, are a common threat that not only do we have to deal with in our business and home environment, but even more in healthcare institutions. In particular, with more UNIX-based systems being replaced with Microsoft products, the threat becomes even more imminent. The question is generally not whether a system will be infected but rather when, and how to react to it.

The federal government has addressed this issue and made this part of the HIPAA security requirements. One of the so-called Administrative Safeguards that have to be in place is the risk analysis that has to be done periodically - which includes the assessment of risk for a virus attack. Protection against malicious software is even spelled out as a specifically required item. Therefore, besides it making common sense, it is a legal requirement.

EQUIPMENT CONTROL

One could therefore assume that every medical device has virus protection software that performs a regular scan and is updated frequently, simply applying the same ground rules that any IT department would implement to protect the users, and ultimately making sure operations are available to serve patients. The problem, however, is that vendors have been very reluctant to release "control" over their equipment. They have had bad experiences in the past because users would add software to their devices which interfere with the operation of the imaging software, resulting in unnecessary service calls and therefore additional cost of maintenance.

Some vendors have taken a hard-line approach and threaten to discontinue or void warranty of their equipment if a user adds and/or changes anything regarding the software configuration. To back them up, vendors use the argument that it is not "FDA-approved." The good news is that the tide is turning, both through pressure of users who simply don't accept these arguments - knowing that HIPAA makes them ultimately responsible and not the vendor, and also because the vendors have had to clean up numerous infected systems during the series of malicious software attacks of the past year.

Another argument from vendors against using virus scanners is that a user should just make sure that the network is protected, e.g. by isolating the physical network through appropriate firewalls and routers. However, I would argue that there is always the chance of an attack from "within". This can take place, for example, from a laptop of a service engineer, which is connected to a device to run diagnostics, and which just has been infected through a virus coming in through his e-mail. Another source could be a floppy disk or CD with a software patch, or even downloaded via the Internet for installing a software upgrade. Therefore, there is no single system that is completely isolated; there is always a change for compromising its integrity

FDA SAYS

Now, let's consider the "not-FDA approved" argument. The FDA guidelines explicitly state that there is no requirement for off the shelf components such as Operating Systems and other utilities to be explicitly FDA approved, such as what is needed for medical device software. However, the FDA guidelines for off-the-shelf components require each medical vendor to validate it. In addition, they need to have a quality system in place which also requires proper validation and verification of all software regardless of whether it is off-the-shelf, as well as implementing software configuration control. Therefore, it is a requirement for the vendor to verify the impact of the virus scanner on the integrity of their software. I cannot imagine that this could take more than one or two days at the most, which is a negligible effort compared with the comprehensive testing and validation of the complete software.

Having arrived at the conclusion that a vendor is responsible to recommend a virus scanner, the next issue is its maintenance. Viruses are known to spread very quickly, which can be days or even hours, and require immediate protection through upgrading the specific profiles of these as part of the virus scan software. Imagine a major manufacturer having to upgrade all their systems worldwide within a few hours; this is not feasible for most of them, at least not with their existing infrastructure. This leaves the responsibility for the maintenance and upgrades to the local IT department. For sure, this is something that needs to be agreed upon up-front between the vendor and user.

This all might seem to make sense; however, there could easily be a disagreement about how to handle the particular details between an institution and a vendor. For example, if a system is suspect of contamination, who would perform the virus checking? Is the impact of re-installing software after the system is compromised part of the regular warranty and/or service agreement? If not, what if the virus was caused by a service engineer, the lack of virus upgrade by the vendor, or if the cause of the infection cannot easily be faulted back to either the vendor or user? The answer comes in a recent publication developed by a joint, international committee of representatives from all major manufacturers, i.e. the joint NEMA/COCIR/JIRA SECURITY and PRIVACY COMMITTEE . This particular white paper "Defending Medical Information Systems Against Malicious Software," lists a set of recommendations for both the vendors and user community.

For a vendor, the white paper recommends:

• Assure system integrity
• Employ defensive system design philosophies
• Host virus checkers where appropriate
• Respect the need for a proper configuration when offering virus checkers
• Offer security-relevant updates and technical assistance
• Respect regulatory and technological imperatives and restrictions

And for end-users, the white paper recommends:

• Use technical network defenses
• Prepare policies, procedures, and user training
• Restrict physical access whenever possible
• Reduce logical interconnections to the minimum
• Establish secure remote access for servicing
• Keep close contact with the vendor
• Implement the Defense in Depth philosophy

The white paper concludes that there is no single set of recommendations, but that the vendor and user have to work together to provide the appropriate secure infrastructure. A key requirement is "defense in depth," which means that there is not a single measure, but a combination of measures so that if one fails, the next one kicks in. For example, what is suggested is a physical isolated network, and a firewall, and virus scanners - with a combination of policies and procedures, which could disallow any e-mails running on these devices and/or other Internet connectivity. In addition, proper documentation of who is responsible for what is critical, especially addressing some of the issues listed above. Malicious software is no fun, but one better make it part of life and be prepared to deal with it, especially in the healthcare environment.

Herman Oosterwijk is President of OTech. He offers training and resources for PACS professionals, available via his Website at www.otechimg.com.