The University of North Texas (UNT) recently performed a survey to
assess PACS security architectures and usage in more than 40
institutions. The facilities ranged in size from 100- to 1,000-bed
facilities, and represented anywhere from 50,000 to one million
examinations per year.
The data in the UNT survey showed several potential vulnerabilities
with respect to security provisions. Taken in light of the U.S. Federal
HIPAA security regulation goes into effect April 20th, these issues are
not only impacting the availability and integrity of Patient Health
Information, but also could represent potential federal HIPAA
violations.
Please note, these 10 recommendations should not be considered a
comprehensive assessment of the HIPAA regulations and/or how they apply
to PACS. (For such an assessment, see PACS Fundamentals, chapter 8,
available from www.otechimg.com.)
Rather, they focus on the most obvious threats and issues, and are
based on the UNT survey and through personal observations we have made
while visiting institutions and talking with PACS administrators.
1. Deploy external & internal firewalls Almost every institution has an external
firewall connecting the hospital core network to the edge network
provided by an ISP and/or WAN communications service provider. However,
most threats actually appear from the inside - usually because someone
inserts a virus-infected floppy or CD, or connects his or her laptop to
a device to be calibrated or serviced. Our survey showed that 90
percent of the institutions do not have the RIS and PACS separated by a
firewall. That means that a compromising situation at either the PACS
or the RIS can impact both systems. Even the HIS is not always
consistently screened. Several security incidents and downtime
situations could have been avoided and/or their scope limited if an
institution would have had these deployed more widely.
2. Implement VLANS to limit access When combined with a gateway, a VLAN is the
perfect complement because it limits the access from the gateway to a
well-defined subnet. For example, one could configure the VLAN to make
sure the CT or MR service engineers access only the equipment they
should have access to. The same applies for any other vendor. In
addition, with proper internal configuration, one can restrict certain
devices to only have access to sub-domains using VLAN technology. Most
of our respondents confirmed they were using this technology; however,
it is not universally implemented at each institution.
3. Make sure your virus scanner is installed and up to date Virus protection is somewhat difficult
because most commercial virus protections do not always do a good job
with dedicated and specialized medical imaging equipment. From personal
experience, my laptop slows considerably after I've installed a virus
scanner for all in-coming and out-going files. Also, it does not make
sense to scan every image that leaves or enters a medical device. There
have been stories about images being quarantined because they fit
certain patterns of a particular virus, and the performance loss for
scanning these files is often unacceptable. Therefore, deploy virus
scanners, but work closely with the vendor to make sure they are
configured correctly and they have been validated by the vendor to not
have any negative impact on the device.
4. Force a service provider to use your gateway The National Electrical Manufacturers
Association (NEMA), in cooperation with several other international
standards organizations, generated a proposal1 which
specifies using a single gateway for remote service access as an entry
point for hospital networks. Based on our survey, 70 percent of
participants implement a gateway. However, it appears that they allow
vendors to install their own gateways rather than controlling the
access themselves: only 30 percent of vendors in the survey are able to
integrate their gateway with the hospital's gateway. Many vendors have
indicated that installing their own gateways is a matter of preference.
Imagine having four different vendors in a department. The institution
is responsible to check the audit trails on these devices, especially
if images and/or other clinical data are accessed or retrieved. From
both cost and management perspectives (somewhere the institution pays
for these devices), a single device makes much more sense.
5. Use the proper VPN configuration Our survey showed that every hospital
supports VPN for remote access, although 20 percent of the participants
reported that they also provide dial-up access. SSL is predominantly
used for remote access for PACS, which works at the communication
level. In other words, a secure connection is established on an
as-needed basis and the information is encrypted so that it can be
exchanged using public networks. In some cases, it might actually make
sense to use IPsec technology and establish a secure "tunnel" at the
applications level. The table below details the differences between
IPSec and SSL, and to alleviate any confusion about when to use which
technology.
6. Deployment of network monitoring tools It is essential to monitor the incoming and
outgoing traffic on a continuous basis. For example, it is required to
initiate periodic auditing of open ports using NMAP and monitor all the
changed files. There are several open source network security
monitoring tools. Some examples of these tools are Tripwire, Superscan,
Nessus, and Ethereal. In addition, there are also several commercial
tools like Lanscope which can give a three-dimensional display of the
network traffic. These displays distinguish between normal and abnormal
traffic.
7. Keep your IDS technology up to date An Intrusion Detection System (IDS) is
predominantly used to find abnormal behavior or activity within the
network. The analysis of the survey results indicates that most (70
percent) of the hospital networks have this mechanism in their network.
However, most of the IDS devices are limited in functionality and are
generally unaware of the specifics of the protocols used, such as
DICOM, HL7 or other proprietary protocols. IDSs are a rapidly evolving
area and it is critical to make sure that one constantly monitors the
new technology and is always alert to any intrusions.
8. Implement your security patches The same caution applies when updating your
operating system to include new patches that close security holes. You
should not implement these as they become available, but rather, work
with the vendor and your IT department to assess the risk. This might
have to be done daily after the patch becomes available, because
hackers are known to close the gap between security holes and create a
new virus or Trojan horse that utilizes the hole. The trade-off between
whether or not to implement the patch and the risk of someone
exploiting it is called patch management and can be formalized using
your specific architecture and implementation.
9. Limit your exposure through the use of a test system It is amazing how many institutions install
new software releases, upgrades, patches, and additional applications
without properly testing and validating them on a non-clinical test
system. It is common practice in the IT world to run tests - there are
actually even special identifiers in the HL7 protocol messages that
indicate test messages, so an application knows not to update the
patient database or perform a lab test (as might have been indicated in
the patient admission or order message). However, most institutions do
not budget for a separate PACS test system, which can be as simple as a
small version of the archive and a few simulators for modalities and
workstations. We contend that with the HIPAA regulation stressing the
preservation of data integrity, one could almost be required to have
such a system. In addition, one also could use the test system as a
back-up, thereby also satisfying another of the other critical HIPAA
security requirements. Based on feedback from those using such a test
system, and hearing what issues and problems were identified - things
that prevented potential major problems with the clinical system - it
seems a no-brainer. We did not ask about the availability of a test
system in our survey, but based on other feedback and observations, it
appears that the majority of the current PACS users do not have such a
system in place.
10. Perform a regular risk analysis The risk analysis is, perhaps, the single
most important item in the HIPAA regulations; in part because every
institution is unique and presents its own set of challenges, resources
and cost limitations. One of the key messages in the HIPAA set of
regulations is that security implementation should be reasonable and
consistent with resources of the institution. In other words, a
doctor's office will have a different security implementation than a
major hospital. However, in all cases, it is impossible to justify any
specific implementation without first performing a well-documented risk
analysis. We mention this because when we visit institutions, we
continue to see potential problems such as workstations displaying
patient information and/or images which can be seen and accessed by
anyone walking by, or workstations left un-attended, inviting anyone to
disabled the auto-log-off. We've seen service personnel accessing
devices without being monitored (until it is too late), and remote
access from people not logged in and/or not monitored. Regular
walkthroughs and risk analyses should be made every few months, if not
monthly.
April 21st is coming soon In conclusion, are we ready for HIPAA? Based
on our survey, and through individual observations, it appears as
though there are still many improvements which should be made. It also
seems there are ad-hoc changes and awareness, not to mention several
vulnerabilities and threats which could impact the HIPAA compliance of
an institution and its data integrity.
Ram Dantu is an assistant professor in the
Computer Science department at the University of North Texas. Herman
Oosterwijk is president of OTech Inc. and a member of the adjunct
faculty of the University of North Texas.