Ascension Health HIPAA Web Site
Maintained by Don Stry, Information Services Division
(812) 228-2131 Email: dstry@ascensionhealth.org
Section: HCFA Internet Security Policy and Encryption Methods
Updated 11/06/01
Ten Best HIPAA Security Tools
by Peter Haigh (Received 08/09/01 from HIMSS)
Introduction
"Reasonable & Cost-effective"
HIPAA clearly presents many challenges to the "covered entities" (CE) that must comply with the legislation and the associated regulations. Not the least of these is that responsibility for deciding how to comply is left to the CE to decide. What a CE must consider is what is "reasonable and cost-effective" for them, based on their size, their current "technology state" as it relates to the regulations. The issue of budgeting for HIPAA compliance is a double-edged sword. A good HIPAA EDI (transactions and code sets) implementation can yield major savings, providing the funds for good security and privacy compliance. As many commentators have stated, "it’s the right thing to do." So, what to do?
264 kinds of reasonable?
Someone (who clearly didn’t have enough to do with their time) counted occurrences of
the word reasonable in the Security Notice of Proposed Rule-making (NPRM). While at first reading the regulations appear quite specific, they deal only with what areas must be addressed. They don’t say what would be considered to be compliant. The final rule (now expected by January 2002) is unlikely to be more specific. Perhaps the rule-makers will be prepared to issue guidelines as they did for Privacy, but don’t count on it. Again, what to do is the question. One useful interpretation of reasonable is that security protection afforded to protected health information (PHI), is that it should be feasible. It is this interpretation that leads to the conclusion that a CE would be deemed compliant if it were to implement security solutions that are "best practices" and "best tools".
10.1 Privacy is about what, security is about how
This is a useful, high-level approach to HIPAA compliance. Security provisions are the means by which CEs deliver the protection of PHI that their Privacy policies, procedures, notices, etc. are intended to provide. The "best tools" introduced in this section of the presentation are offered with this approach in mind. Note that Security must include consideration of integrity and availability, not just confidentiality, which is a narrow definition of privacy.
10.2 Good guys & bad guys will BOTH use the network
Another principle underpinning the "best tools" approach is that most CEs either are or will be using automated, network technology based solutions to process and store PHI. (Note that this paper does not extend to covering security for written or oral communications that we expect will be detailed in Security regulations for non-electronic
PHI. Issuance of separate regulations for these types of PHI is expected, with coverage and compliance dates presently unknown.) While conceptually it is possible to consider some likelihood that PHI could be inappropriately accessed/disclosed by some kind of direct invasion of files, databases, warehouses and archives, realistically the risk of access will conform to means of by which authorized users get to the information – over the Ces network. In this context the network consists of the CEs internal network, the
external network based on service provider facilities (e.g. the public switched phone/data network), and the Internet. It is important to note that most commentators agree that the risk of inappropriate access is split 80/20 between malicious/curious "insiders" and external "hackers".
10.3 Access control
Recognizing that the network is where the risk of inappropriate access exists leads to the conclusion that controlling access through security technology is a most important area for the application of best tools. Looking at access control as a two-stage process is recommended. Stage one controls who gets on the network, and Stage two controls what PHI the user who satisfies access control is actually authorized to use.
User-id + password versus tokens versus biometrics
Can user-id and password be considered sufficient protection for access control? Most CEs current practices involving infrequently changed, easily guessed, stored under keyboards, "post-it" noted on monitors or in unlocked desk drawers, will clearly not pass muster. Even a well-administered password procedure is still subject to relatively easy penetration. The widely available program CRACK is considered capable of revealing 10% of the passwords issued under good procedures. How many passwords do you need to compromise a network? At the same time, care-givers, whether nurses or physicians,
PHI users with probably the widest access to PHI, commonly complain that remembering
frequently changed passwords is too difficult and distracts their attention from their primary role.
Are there other ways to increase the certainty that someone seeking access is who they purport to be? Yes there are. Software/hardware token systems, one-time passwords generated Secure-ID cards and the like, increase the level of security by establishing that the person signing on is who their token says they are. Stronger yet, and more convenient are biometric scanning devices such as thumb-print, voice-print, iris scan, etc. Both "ease of use" and security can be improved through the deployment of biometric readers and the associated identity verification system. It’s already possible to procure keyboards with a built-in place for a thumbprint reader. A solution of this kind clearly offers the potential for improved certainty of user identification, and there’s nothing for the user to have to remember. The market size, learning curve effects which has produced such favorable reductions in the cost of PC and network hardware can be expected to sharply reduce the cost of biometrics, if healthcare and other industry markets embrace this as a best tool.
10.4 Authorization control
The second stage of controlling access to PHI couples a "profile" by user and position/job description, that limits the scope of access to PHI is one or both of the following directions:
- Vertical – by application
- Horizontal – by patient
Today, methods of implementing authorization control are not as clear-cut as those for access control, since the solution will vary with the IT application architecture of a specific CE. CEs that have implemented a single or primary IT application vendor is likely to find it easier than those which have pursued a "bets of breed" approach. "Single sign-on" solutions behind access control offer some potential to be able to establish user profiles. However, the current level of single sign-on is considered to increase rather than decrease the level of risk of unauthorized access, since it creates a "bulls eye" target for
hackers and others attracted by technical challenge. It seems that there is a technical-market opportunity for software suppliers to improve the robustness of single sign-on, or
user profiling. This will be a space worth watching for new solutions.
10.5 Business continuity, contingency planning, disaster recovery
Whatever the reason why HIPAA regulations call for this to be addressed, its clearly a requirement. Some suggest that its because the rule makers expected that under disaster recovery situations the security "perimeter" might be weakened unless this was clearly addressed in the business continuity plans. Others see the requirement as important, since when electronic patient records are widely used availability of these records at the point of care will be vital to diagnosis and treatment. This means that two important "best tool" approaches will be needed, redundancy to reduce the likelihood of a system/network outage, and disaster recovery in the event that an outage occurs.
10.5.1 Redundancy
How many CE networks have been designed with redundancy as a vital capability? We
suspect not many. However, the "best tools" approach would always have considered this important. Good network planning and design practice has always included duality in all network links except the last one to the individual network node. In this last link it is usually considered feasible to handle a single node outage by having users sign on and access the network from an unaffected, adjacent workstation. The "universal" requirement is for back-up power to be available, such that communications closets should have emergency power connections and/or battery back-up, and some number of network nodes should have the same.
10.5.1.1 LAN Redundancy
What should this consist of? Redundant, backbone and "middle-bone" (e.g. riser) cabling, dual homed to redundant switches and routers is the right answer. Among the switch and protocol selection criteria should be how fast and automatic is the fail-over, how does the switch actually sense a link failure.
10.5.1.2 WAN Redundancy
Here redundant links (perhaps at lower speed, e.g. frame backed up by ISDN, DS-3 by DS-1) should be ordered, in-place and tested. Routers/switches/other edge devices should be capable of sensing a link failure and switching over to the back-up link automatically. As a general rule WAN links provisioned on SONET rings, (which have 50 millisecond service recovery to the alternate ring route in the event of a failure) would be preferred over those implemented on point to point facilities. Wherever possible carriers should be asked to provide services for the primary and back-up links via geographically separate building entrances, connected to different carrier switching centers (sometimes called Central Offices, or COs).
10.5.2 Disaster Recovery
Do you have a plan? Do you have a back-up site? If the site is remote, as it most likely is, do you have WAN links in place so your users can access the information they need? OK, so you can run your applications, are the recovery site and its links properly secure? Need for a whole paper on this topic, but not here!
10.6 Entity & data authentication
CEs accept responsibility for the accuracy of PHI received from others, both as to the source of the information and its integrity. Did the information come from the source that is claimed? Is there any evidence that the PHI may have been altered?
10.6.1 Digital certificates
Implementation of Public Key Infrastructure certificates indicating that the source can be trusted to be "who it says it is", is a best tool that is increasingly available. Many Secure/VPN solutions come with Certificate Authority services included.
10.6.2 Checksums, etc.
Old-fashioned maybe, but checksums are the kind of technical solution for validating the completeness of data transmissions dating from the time when WAN links at slow rates of 2400/4800 bits per second could not be reliably supported by the public switched network fabric of the early 1970s. Today these techniques can be applied to check whether bits have been added or deleted by an intruder who wasn’t careful enough to redo the checksum as well.
10.7 Tracking malicious &curious users/intruders
HIPAA’s security rules make it clear that CEs are expected to attempt to identify suspicious activity, and respond to actual security incidents when they occur. This presumably means that the CE should have some means to know when there has been an incident.
10.7.1 Logging
HIPAA calls for a variety of things to be logged. Logging as it relates to HIPAA security has to do with capturing information about who has what access-authorization rights, how and when these rights were initiated, changed or revoked. Logging should also capture patterns of activity such that differences between normal and unusual activity can be perceived.
10.7.2 Intrusion detection
Intrusion detection (ID) systems offer the promise that patterns of unusual activity can be spotted as they happen, rather than though manual or automatic review of activity logs. Solutions offered today can clearly be improved upon, as more knowledge can be gained about what represents an intrusion. The ability for ID systems to keep pace with the increased speed of network links is another area that needs and will receive attention. Vendors are beginning to promise Intrusion Protection (another IP acronym), a step beyond ID that will stop intruders rather than needing to detect them.
10.7.3 Surveillance
Tools that permit authorized network administrators to monitor individual user activity on the CEs private network are technically feasible. They may even exist already. The issue is less a technical matter than an ethical dilemma of whether such surveillance is legally/constitutionally proper – note all the changes over the years in the legality of "wire tapping". Yet tools already exist and are being used to document and limit users’ access to Internet sites/services that do not appear to be work-related.
10.7.4 Vulnerability assessment
While surveillance is a potential best tool for internal users, vulnerability assessment tries to define points of weakness that an external miscreant (hacker, etc.) might be able to use to access PHI directly, or might use to obtain access privileges that will permit them such access in the future. Vulnerability assessment emulates hacker activity by using the "hackers tool-kit" to attempt penetration of the CE’s network from outside, via the public switched network (e.g. dial-up lines) or the Internet. However, the assessors are "white-hat" security specialists not hackers (even reformed ones). Results of vulnerability assessment, sometimes referred to a penetration testing provide a CE with knowledge of where the risk points are so that they can be considered for closure.
10.7.5 Firewalls
Isn’t a firewall all I need to protect a CE from Internet-based security threats? At first sight it seems the answer is yes. Not! There are several ways in which firewall effectiveness is limited.
__ "By definition" CEs want certain Internet traffic, e.g. WWW-site visitors and E-mail to reach them
– malicious Internet traffic can be made to look like HTML web access, and E-mail can carry evil payloads.
__ Firewalls are frequently incorrectly configured.
__ Firewalls themselves are subject to attack, and have known/suspected vulnerabilities.
Double firewalls, "demilitarized zones" and other techniques can be used to improve firewall effectiveness, but if the firewall logs are never examined to look for intruder "finger-marks", the investment in firewall technology is largely wasted. Also don’t forget the need to deploy "personal firewalls" for all full-time or occasional telecommuters.
10.8 Encryption
Why not try something radically different? Don’t spend so much time and effort trying to prevent disclosure of PHI, make the PHI essentially useless by encrypting it. This excellent security approach can be implemented on LANs as well as Secure/VPN or other WAN solutions. Are there any downsides? At least 2, latency in performance due to encrypt-decrypt processing, and the restricted ability to look inside encrypted packets for routing and above layer 2 switching. Nevertheless CE’s with traditionally wide-open, hard to secure networks are considering universal encryption as the simplest and least expensive route to HIPAA compliance.
10.9 Other Recommendations
10.9.1 Software and Hardware Discipline
Not a HIPAA requirement, but a recommended approach, this approach requires a CE to define standard configuration(s) for all clients and servers. As a matter of policy all non-standard devices would be replaced prior to the HIPAA compliance deadline. furthermore, as a matter of policy and procedure, workers would be forbidden to introduce ANY non-standard hardware or software, even screen saver photographs.
10.9.2 Virus Protection
There is no doubt that a virus weakened network is more vulnerable to attack. Indeed distributed denial of service zombies, worms and other creatures enter non-virus protected networks with greater ease. So universal deployment of virus protection software is vital for HIPAA, as a best tool Regular use of the tool, required by policy and procedure, is a matching best practice.
10.10 In conclusion, a disclaimer
One "reasonable reason" why the rule-makers chose to describe their regulations as "technology neutral … deliberately general guidance" is because security technology solutions will not only change, they will improve. Some areas where improvement can be expected have been noted above. Others developments are unknown at this time. Likewise it can be expected that users and hackers will become more sophisticated in the ways they intrude on CE’s networks to inappropriately access and disclose PHI.
Even today, this presentation does not purport to be a complete review of best tools. What has been attempted is an illustrative review of what CEs should look for as they strive to achieve the right balance between theoretical compliance requirements and what’s reasonable and cost-effective for them to establish improved security solutions for the protection of PHI.
Finally, note that most of best tools are of little use if not they aren’t used in the right combination. Only a few can be considered automatic. An important part of best practice, is the way in which use of best tools is mandated by policy and procedure.
END