HIPAA Security & Compliance

Introduction

The HIPAA Security Rule became final in February 2003, and Healthcare Organizations (HCO’s) are now working towards the compliance deadline of April 21, 2005 which has already occurred. The final
HIPAA Security Rule has a flexible approach; the recurring theme is that HCO’s must evaluate their risks and implement reasonable and appropriate measures. But how does an organization determine
what is reasonable and appropriate? One of the most important ways is to look at best practices in healthcare information security.

“Best practices” are a set of methods and processes based on generally accepted principles, as determined by information security professionals. They are guidelines for developing and
implementing security policies and procedures, and deploying technologies, in order to comply with regulatory requirements such as HIPAA, and protect business interests. For example, best practices
in information security help protect an organization from risk of litigation liability, the loss of intellectual property, loss of money, and/or a ruined reputation.

HCO’s face a tight timeline for HIPAA Security compliance. According to URAC, which provides HIPAA Privacy and Security accreditation, a compliance program should begin before the end of 2003 and
include awareness, assessment, and implementation phases. At the same time, HCO’s are under pressure to increase their use of technology in order to improve patient safety and the quality of care,
increase efficiencies and reduce costs. Over the next few years, HCO’s will be striving to take full advantage of Internet technologies, while ensuring the privacy of their patients and members
and the security of information.

This compilation of best practices was derived from our experience in information security and in working with HCO’s to implement security measures suited to their environments.

The Road to Compliance

Awareness

Initially, the security rule should be analyzed and its impact on the organization determined. An information security official (CSO, CISO, CIO, Director of Security, etc.) should be appointed; and
this position should be backed at the senior executive level. The senior executives within the organization should be educated on the implications of the security rule and what needs to be
accomplished to be in compliance. They should also be advised of a high-level timeline and given target dates for major milestones along the critical path. If a robust information security program
does not already exist within the organization, one needs to be developed. The information security program should have a clear direction and vision, with a mandate to comply with regulations but
also to meet business objectives. One of the most important tasks is to determine what information within the organization falls under HIPAA’s definition of “protected health information (PHI)
“, where it resides, how it is accessed or transmitted, and who has and needs access to it. (Protected health information is defined in the HIPAA Security Rule §160.103)

Assessment

The next step towards HIPAA Security compliance is the assessment phase, most importantly, performing a risk analysis. A risk analysis is a key requirement of HIPAA Security and will be the basis
from which implemen-tation decisions are made. A risk analysis determines what needs to be protected (Critical assets such as hardware, software, data, information, etc.), the possible threats and
vulnerabilities, the probability of various security incidents, and the impact to the organization. Based on the organization’s tolerance for risk, decisions are made regarding: whether to accept
the risk (do nothing since the costs to protect the asset is higher than the potential loss), assign the risk (get insurance rather than implement controls to protect the asset), or mitigate the
risk (by implementing security controls). If risk mitigation is the selected option, the organization must determine the extent of risk mitigation. This whole process must be extensively documented
to show due diligence in the risk analysis phase. Once this process is completed, projects should be defined and prioritized.

Implementation

The last step in the compliance process is implementation. It includes the formal creation of an information security program. The program should include plans for a continual risk assessment
process, creation of security policies, procedures, guidelines, and baselines as well as training and education. Security policies are the foundation of an effective information security program;
they define the expected state of security for the organization.

As a matter of course, and given the tight timeline to compliance, an organization will need to evaluate the use of internal and/or external resources; an organization may need to increase staffing
and/or call on out-sourced, experienced professional services personnel to assist in the process.

Implementation will involve the acquisition and deployment of the required security technologies to support risk mitigation efforts (based on the organization’s risk analysis). Organizations will
need to evaluate various technologies and select vendors.

Best Practices for Administrative, Physical and Technical Security

Conforming to the convention of many industry security standards, the HIPAA Security Rule categorizes the required controls into three sections: Administrative, Physical, and Technical Safeguards.
The following section outlines best practices in each of these categories.

Administrative Security

The Administrative Security area is often referred to as the envelope that wraps around the entire information security program. It communicates direction, establishes expectations, and outlines
disciplinary actions for non-compliance. This is an area where significant effort should be focused since it provides the fundamental principles upon which the entire information security program
is based. It also serves as the central source of documentation for HIPAA compliance reviews.

The first step in a review is typically to look at all the pertinent documentation including documentation that supports the decision making process.

Security Policies and Procedures

• Policies are the foundation of an information security program. They define the expected state of security for an organization. They also define the technical security controls that protect the
  electronic form of protected health information.

• Policies and procedures should be approved and backed by senior management.

• Physical security requirements should be outlined including what are restricted facilities and what type of access method is required to gain entrance to these areas.

• Logical perimeter control includes requirements for accessing the network resources and assets attached to the network from remote locations (i.e. VPN, dialup, private WAN circuits, etc.).
  Connection requirements should be outlined as well as provisions for authentication and authorization.

• Tiered network design requirements should be documented such that a zone-based architecture can easily be derived out of these requirements. For example:

• Authentication requirements for accessing various components of the network or assets that reside on the network should be detailed, making it clear when simple authentication is sufficient and
  when strong authentication is required (see “Authentication Guidelines”). It should also state the requirements for authentication at the workstations and whether there are distinctions between
  certain workstations and others (some that may have access to protected health information (PHI) and others that may not).

• Jobs should be classified by function into roles that dictate employee access and authorization for systems and assets on the network. This classification is an ongoing process that must be
  diligently maintained in order to be effective.

• Backup requirements should document frequency required for each class of systems or data and how the backup media should be handled (on site versus off site and archive retention period.)

• Data protection requirements specify minimum requirements for the handling of different classifications of data (confidential, sensitive, eyes only, PHI, classified, secret, etc.). These
  requirements should differentiate between standards established for transmission versus storage.

• Personnel security policies should outline the minimum standards for background investigations, personnel record keeping, and drug testing for employees.

• Sanction policies should provide the human resources department and Compliance department with the necessary leverage to impose proper sanctions for infractions of the policies and codes of
  conduct.

• Requirements for a disaster recovery and/or business continuity plan should be spelled out in policy.

• Provisions for an incident response plan and incident response team should be documented. The goal and purpose of the plan and team should be specified. The charter for producing the plan
  should be delegated to the information security official.

System Baselines

• System baselines should be developed for each operating system in use. Baseline documents should include instructions on disabling unnecessary services, hardening the operating system and
  specific applications, and vendor patch management.

• All systems should be properly configured and tested before being placed on the network or in service.

• Default system passwords should be changed prior to deployment of any system, network, or hardware component.

• OS patch management should be documented and the process communicated clearly to system management personnel.

• Systems should be inspected and periodically audited for compliance with patch management and baseline compliance as well as vulnerabilities.

Configuration Management

• A configuration management plan covers all networking equipment and any assets that are attached to the network. There should be established maintenance windows for network personnel to use for
  routine maintenance activity.

• When changes to systems or assets attached to the network are required, there should also be changes to the user-level documentation such as new training material.

• A configuration management committee should meet regularly to approve changes to the shared environment. This committee should be focused on processes and assure that adequate testing and
  planning have been accomplished prior to changing the environment.

• All changes to the shared environment should be approved by committee and analyzed as to whether the proposed change will require modifications to the disaster recovery or incident response
  plans.

• Provisions should be in place to provide for automated “pushes” of updated software (including operating system patches) to the workstations on the network.

• Desktops should all be equipped with antivirus software and updates to the antivirus signature file should be “pushed” as they become available.

• An inventory of programs and executable code at the desktops should be maintained (a set of standard desktop images helps this process tremendously) to help detect unlicensed software use.

Incident Response

• An incident command center that is well stocked with the necessary supplies, equipment, and backup systems should exist to support operations in the event of an incident that disables part of
  or the entire data center.

• Each staff position in the command center is identified by role and should have a minimum of two existing staff personnel that could fulfill the duties of that role.

• Work force should have one single phone number to call to report any type of incident.

• The help desk personnel should be given training to help them recognize patterns and situations indicative of security related incidents.

• Help desk personnel should receive specific training to help them avoid falling prey to common social engineering techniques.

• Specific personnel are designated responders for security incidents and should receive training on how to collect evidence correctly and maintain a proper chain of custody.

Physical Security

Though the final HIPAA Security Rule specifies coverage of security measures for the electronic form of protected health information (PHI), physical security still plays a large role in the
assurance of information security for electronic storage and transmission media. The old information security axiom still holds true – “Anything I can touch, I can own”. If we don’t control
physical access to information assets, it’s not a question of if information assets will be compromised, but more a question of when.

Physical Access Control

• Swipe or proximity access cards should control and provide an auditable log of access into and out of restricted areas; and include mechanisms for granular control over day(s) of week, time(s)
  of day, etc. for each card.
• Guest badges should be used for non–employee access to restricted areas. All guests should be escorted and access to restricted areas should be under direct supervision of an employee.
• Workstations should use privacy screens that prevent viewing the screen unless the viewer is sitting directly in front of the screen.
• Transcriptionists and coders that work from home or off site should have two internal hard drives that are set up for booting their systems. One should be for work related to transcription or
  coding. The other should support whatever other function they may use that computer for (i.e. another customer, other parts of their work, or personal use).

Data Center Access

• Any personnel that are not authorized to access the data center should be required to sign in and wear a special data center visitor access badge.

• Authorization for vendor system maintenance personnel should be verified prior to granting access to the data center.

• An employee should escort vendor system maintenance personnel and their activities monitored by either an employee or a digital surveillance system.

Media Controls

• On site backup media should be stored in an environmental-resistant (i.e., water, fire, oxidation, etc.) container away from the data center.

• Portable devices including, but not limited to, laptops, PDAs, floppy disks, USB storage devices, and Firewire storage devices should be positively controlled in areas where PHI can be
  accessed. Examples of appropriate control measures are educating employees in the proper use of portable media and ensuring that visitors are always escorted and never allowed unattended access to
  areas where PHI could be migrated onto portable media. Policies regarding the use of portable media should be well established, backed by senior management, and be well communicated.

• Portable devices including, but not limited to, laptops, PDAs, floppy disks, USB storage devices, and Firewire storage devices should have security enabled to protect any PHI contained on these
  devices. The type and depth of security will be different for each type of device. Most modern PDAs support a full suite of security functions (password on startup, encrypted file systems,
  authentication, etc.) whereas most generic storage devices have minimal security built in and might require a third party encryption tool to use securely.

• File protection tools should be deployed for confidential data or PHI that is stored locally on workstations and even centrally on file servers including, but not limited to, Microsoft®
  Word® documents, Microsoft® Excel® spreadsheets, and Microsoft® Access®/SQL® databases. Encryption software can be used to protect data stores and allow access by authorized
  personnel only.

Media Disposal

• Paper documents should be securely stored. Shredding, pulping, and burning are acceptable methods of disposal.
• Acceptable methods of disposal for prescription bottles, labels, CD-ROMs, and other similar items are burning, pulverization, or a high-pressure compression process.
• Hard disk drives and other read/write media (whether silicon or magnetic media) should be sanitized by overwriting at least three times with random patterns of “1’s” and “0’s” before they
  are put back into service elsewhere or disposed of.

Technical Security

This section covers a very wide range of topics including everything from access to information assets (both locally and remotely), network infrastructure architecture (flat or multi-tiered) and
end-user workstation configuration (session time-outs and automated, password-protected screen savers).

Access Control

• Access control takes business rules and security profiles into consideration to establish and enforce policy around which users are granted the privilege to access which resources. The selected
  level of granularity for access control will depend on the organization’s risk analysis and the particular application. For web environments, several levels of access management are possible:

• For applications containing protected health information (PHI), fine-grained authorization protocols should be implemented, to control users’ actions such as read, modify, delete, copy, and/or
  sign a record, etc. Controlling access based on job function (role-based access control) can help meet the minimum necessary provisions of HIPAA Privacy.
• Applications that process, display, or manipulate PHI should have automatic time-out mechanisms that engage after five minutes of inactivity. This protects against users who do not formally log
  out of the application.
• Workstations should support multiple user logon sessions and require successful authentication prior to allowing access to any data on the system.
• Where possible, a centralized user management system should be used for providing authentication and authorization of users accessing the network or any assets that reside on the network. This
  model pushes authentication and authorization for access to all applications, data, or systems to a single source of data. Centralization of the management and storage of user data greatly enhances
  security and improves efficiency.
• Implementing Single/Simplified Sign-On (SSO) solutions with web-based front ends (such as portals) can address user account centralization with legacy systems that have no standard interface to
  communicate with the central user store (i.e. systems that don’t understand LDAP).
• There should be a single source of “truth” for user identity. It is recommended that the designated security official’s organization be charged with defining the “landscape” of the central
  user identity store. This activity would include:

• It is recommended that the HR/Payroll organization be involved with operation and maintenance of the user information (adding new users when new hires are brought into the organization,
  deleting users when employees leave the organization, changing user information when users change job functions, roles, titles, etc). A web access management system can assist in this process by
  centralizing authentication and authorization, so that if an employee is terminated, their identity and access privileges can be immediately revoked across all applications.

Authentication Guidelines

• Authentication is the process of independently verifying the identity of users before they are allowed access to critical data assets, perform electronic transactions or manipulate electronic
  records. The strength of authentication method is based on the number of factors it uses in verifying the user’s identity.

• The three most common factors used to verify identities are:

• The selection of an authentication technology will depend on the organization’s risk analysis and the particular application; and consider the value or sensitivity of the information to
  protect, balanced against usability, deployment and budget. (For more information, RSA Security’s “Authentication Scorecard” provides a framework for evaluating and selecting the right
  authentication technology.

• Authentication requirements should be outlined for categories of access to the network or resources; for example remote versus local access. Remote access to resources should require strong
  authentication. The same resources might only require single factor (i.e. password) authentication when accessed locally. Physical access controls provide a layer of security when users are
  accessing information locally; for example, users are allowed to enter facilities only if wearing an ID badge. However, when users are accessing information off site from a remote location, this
  layer of physical security does not exist; therefore remote access should require two-factor authentication. Specified critical assets might require strong authentication regardless of whether
  they’re accessed locally or remotely.

Remote Access

• Especially if employees, staff, physicians, etc. are accessing PHI over the Internet (via a portal or VPN, etc.), healthcare organizations should use two-factor authentication.

• For vendor access to systems, the help desk should maintain possession of the vendor’s tokens and issue the one-time-password to the vendor via an authenticated phone call each time access is
  required.

• All modems that are deployed in the environment should have a well-documented business justification that cannot be met in any other manner and should be periodically reviewed for continued
  applicability and need.

• Modems deployed with remote access software enabled (such as pcAnywhere or gotomypc) must be configured properly and use two-factor authentication.

Audit Process

• User activity should be tracked and monitored to ensure proper enforcement of policy and to determine if there have been any unauthorized disclosures of PHI. The level of detail and frequency
  of logging and reporting will depend on policy and the particular application.

• Logs and reports generated by the authentication and access control systems should be used to monitor and analyze users’ access to resources, applications and files, including the users’
  actions such as viewing, modifying or deleting information.

• Logs should be configured based on security policy, time-stamped and strictly limited to security personnel.

Password Guidelines

• Policies should be set for minimum password requirements (such as length, composition, reuse, etc.) and users should undergo man-datory training on how to select a strong password.

• Initial user passwords should be generated randomly and communicated to the user in a sealed envelope and password changes should be required periodically (90-120 days) as well as upon initial
  login.

• There should be a clearly defined process established for resetting user passwords through the help desk. The help desk should be trained on what the minimum requirements are for establishing
  positive identification of a user prior to resetting the password.

• All systems should be configured with auditing enabled. Logging should be shipped to a central logging server to prevent tampering on the local system. For critical systems, logging can also be
  printed on a line printer for daily review.

• Data owners should periodically receive an access control list detailing who has access to their systems or data and what privileges they have.

• User activity should be logged when there is suspected unauthorized activity. Users should be randomly selected for audit with the output of the audit provided to their manager. All
  administrators’ actions should be logged.

• Banners should be deployed that flash up on any access to the network or resources that specifically communicate that there is “No Expectation of Privacy” and that “System Activity Is Being
  Monitored”.

WAN Connections

• WAN connections should be well documented as part of the network perimeter.

• Business associate WAN connections should be terminated in a central location (i.e., extranet zone) for ease of management and uniform policy enforcement.

• Private WAN connections are not automatically exempt from further scrutiny and evaluation with respect to HIPAA Security Rule requirements for the protection of PHI (i.e. depending on the
  nature of the data traversing the link, it might still require an encryption solution).

• All business associate and extranet connections should be subjected to the risk management process.

Zone-Based Architecture

• Defense in depth should be integrated into every project. Security does not stop at the perimeter of the network (where the Internet connection terminates). The network should be divided into
  zones of differing security with areas of high risk being isolated from areas of lower risk as illustrated in figure 2.

• Internal LAN architecture should make use of switches and their VLAN technology to isolate collision and broadcast domains, but also to protect against unauthorized access to traffic being
  transmitted over the network. Access control lists and firewalls should be used to afford specific assets an additional level of security.

• Firewalls and access control lists should be deployed with a “default deny” policy subsequently specifying specific traffic to permit rather than a “default permit” policy with certain
  traffic being denied.

• Firewalls should fail closed rather than open.

• Architecture of the network should prevent disclosure or theft of PHI even if any single given access control mechanism (say a single firewall or access control list) was to be compromised.

Detection Solutions

• A holistic approach to incident detection should be implemented. The detection mechanism should take into account network as well as host based activity and be capable of detecting common
  patterns (signatures) as well as anomalies.

• File system integrity monitoring systems (such as Tripwire or FTimes) should be used to protect static data from unauthorized modification.

• A resource should be designed to detection activities. The first step in any Incident Response (IR) plan is detecting there was an incident in the first place. Detection won’t happen if no one
  is responsible for watching.

• There should be a well-documented and established incident escalation path.

Wireless Security

• Wireless access points should be configured to not transmit the System Service Identifier (SSID) in the beacon frame (doing this requires that an attacker know the network is there and what the
  exact SSID is in order to join it).

• Wireless access points should be encrypted using the strongest encryption available at the time (WEP 128 at the time of writing). It should be noted that Wired Equivalent Privacy offers a
  minimal measure of security and as such it (by itself) should not be considered adequate protection of PHI.

• IPSec (IP Security) tunnels should be established between the wireless client workstation and a trusted termination point on the wired network for the secure transmission of PHI.

• MAC address authentication should be employed where possible as an added measure of security for clients joining the network.

• Wireless networks should employ the 802.1X/EAP (Extensible Authentication Protocol) end-to-end framework for security. This framework provides for mutual authentication between the wireless
  client and the authentication server (typically a RADIUS server), dynamic assignment and management of encryption keys, and a central policy to control session time-outs and key redistribution.

• The physical premises should be assessed periodically for rogue access points. In general, there are two types of Wireless LANs (WLANs). The ones we know about and have configuration control
  over and the ones we don’t know about and have no control over.

Conclusion

Complying with HIPAA Security involves the assessment of risk and implementation of reasonable and appropriate measures, which can be determined by looking at best practices in healthcare
information security. Based on the risk analysis and the organization’s overall culture and risk tolerance, policies and direction are set, procedures and processes implemented and technology
deployed.

Some of the key technologies required include access control, data integrity, authentication, audit controls and encryption. These are Cotère’s core competencies and thereby the basis from
which Cotere proves it’s compliance with all HIPAA laws and standards.

References

• The Latest and the Best (Practices): HIMSS Annual Conference, February, 2003, San Diego, CA (Views from the Top)

• Walsh, Tom “Best Practices for Compliance with the Final Security Rule” Journal of Healthcare Information Management, Volume 17, Number 3, Summer 2003, published by HIMSS