"It is impossible for ideas to compete in the marketplace if no forum for
  their presentation is provided or available."           Thomas Mann, 1896

---

HIPAA - FINAL SECURITY RULE
Information Security Reference Guide

By Gary Swindon
Contributed by Sygate Technologies, Inc.

Abstract

The HIPAA Final Security Rule is divided into three broad categories of safeguards; administrative, physical, and technical and contains 42 security specifications. This reference guide lists the requirements of the Final Security Rule in point format with the action that needs to be taken in order to achieve compliance for Healthcare Operations by April 21, 2005, the final compliance date. More to the point it provides explanations for each specification in plain English.

Introduction

The HIPAA Final Security Rule is the third of the “big three” HIPAA rules (Transactions and Code Sets, Privacy, and Security). Although the title tends to invoke thoughts of technical or computer based security techniques alone, it is much more focused on security as a business process. The rule itself is broken down into three broad areas of safeguards; administrative, physical, and technical. In each of these areas the Federal Government has created a set of standards that healthcare organizations must meet in order to be compliant with the rule.

Some standards must be implemented exactly as the rule states and the balance of the requirements can be met in a way that the organization judges is appropriate for the prevailing conditions. However, organizations do not have the latitude to ignore any of the standards.

In addition to being a law aimed at the healthcare industry, the Health Insurance Portability and Accountability Act of 1996, or HIPAA, has the potential to cause far-reaching impacts on enterprises in unrelated industries, such as banking, accounting, and financial services. This extraordinary reach originates with the HIPAA provision governing the “business associates” of healthcare organizations. Basically, any entity that provides services involving patient-confidential data for a healthcare organization is required to adhere to the same standards of security and protection that the healthcare organization must follow for the use and disposal of confidential data. Of the several rules that comprise the law, two contain the “heart” of the regulation: the Privacy Rule, already in effect, and the Final Security Rule, with a compliance date of April 21, 2005.1 These rules are mutually supporting; the Privacy Rule addresses the necessary parameters of protecting and using personal healthcare information; and the Security Rule addresses the security posture needed to support the Privacy Rule.

The Security Rule has a strong element of common sense attached to it in that covered organizations are specifically charged with considering how large the organization is, how complex, what resources are available and how much remediation efforts will cost. The basis for the regulation is the consideration of the business risk associated with the information processes and the relationship that they have in supporting patient privacy. Specifically, organizations are charged with evaluating their risk, taking steps to mitigate it, and accepting the residual risk as a cost of doing business.

The focus of the rule while technical in flavor, does indeed address how computer and other information systems are to be used and managed.

It also addresses such things as the physical security of the devices, the buildings that they are housed in and the methods that are employed to manage the workforce. Taken as a whole, the Security Rule compliments the Privacy Rule and extends a management framework that makes ongoing support of Privacy efforts feasible and possible.

The rule emphasizes policies and procedures for its compliance deadline of April 21, 2005. Specifically, we must ensure that our policies and procedures are properly documented, internally consistent, and enforced (when violations occur). In addition, we must make some physical and technical efforts to ensure the safety and security of our information assets. The rule is not intended to be a punitive standard but rather a framework for a safe patient care environment.

1 There is an exception to the Final Security Rule compliance date for small covered entities that extends the compliance date one year.

Since breaches in patient confidentiality and privacy involve lapses in security practices, the Final Security Rule is covered by the same penalties as the Privacy Rule, both civil and criminal, and is enforced through action taken by the Office of Civil Rights, Department of Health and Human Services. The mechanism is simple, if a patient believes that their privacy has been breached, they may file a complaint with the Secretary of Health and Human Services who then provides the compliant to the Office of Civil Rights for investigation and determination of necessary action. This determination can include remanding the complaint to the Justice Department for suspected criminal activity. Should the complaint be validated, a company can face either civil penalties of up to $25,000 a year for each type of incident or, when criminal liability is proven, fines ranging from $50,000 and 1 year in prison, up to $250,000 and as much as 10 years in prison for the people found guilty.

The Privacy and Security Rules both require an active and aggressive risk management program that includes the assessment of risk, risk mitigation activities and acceptance, in writing, of the residual risk that the organization is willing to accept as a part of “doing business.” This program is a fundamental requirement and must be done on a continual basis (164.308(a)(1)(i)). The notion of risk in this context involves both administrative (policy and procedure) activities and technical infrastructure blended in such a way as to facilitate the enterprise achieving compliance.

HIPAA compliance therefore, must be continuous and testable at any time — with an emphasis on the testable part. In addition, the regulation is forever; short of the Federal Government changing its collective mind, these rules and their requirements are not going away. Thus, the HIPAA rules require a level of governance that up to this point has not been commonplace. Boards of Directors, outside auditors, corporate management, and corporate executives must be able to assert and prove compliance at any time.

Standards, Citations, Specifications, and Impact on Healthcare Operations

In the table below, standards or specifications with an (A) or an (R) mean:

(A) ADDRESSABLE - We must assess whether each implementation specification is a reasonable and appropriate safeguard in our environment based on the likely contribution it would make to the protection of electronic health information. If so, then we must implement the specification as written. If not, then we must document why it is inappropriate for us and implement an equivalent alternative measure that is reasonable and appropriate. We may take any steps to achieve compliance in keeping with:

• our size, complexity, and capabilities;

• current infrastructure and our technical capabilities;

• the costs of security measures themselves;

• the probability and criticality of potential risks to protected electronic health information that we generate or receive.

(R) REQUIRED - When a standard is marked as required then we must implement the specifications listed. The policies and procedures that we implement must be maintained for six years after the effective date of the policy or six years from the date the policy is no longer in force; whichever is longer.

Items with an asterisk (*) below are security specifications that can be addressed for compliance by having the Sygate solution running in the network. The distillation of all of the requirements, rules, and efforts leads directly to a security program that will be heavily dependent upon knowing, at any time, with certainty, that the organization is secure, compliant, and ready to support governance efforts.

HIPAA Final Security Rule: Administrative Safeguards

Security Management Process 164.308(a)(1)

We must implement policies and procedures to prevent, detect, contain, and correct security violations.

• Risk Analysis (R) * We must conduct accurate and thorough assessments of the potential risks and vulnerabilities to the confidentiality, integrity, and availability of electronic protected health information held by us whether or not we created it — such as with information that we come to have through referrals etc. from an outside party. This also includes the potential impact on our business.

• Risk Management (R) * We must implement security measures sufficient to reduce risks and vulnerabilities to a reasonable and appropriate level to comply with section 164.306(a). The bottom line is that we must take steps to protect against any and all threats and hazards to protected information in our possession or that comes to us from outside associations. The key phrase in risk management is “reasonably anticipated” and the requirement applies to managing our workforce when they might come into contact with the protected information. It also requires us to consider cost, complexity, and ability in determining what we do to protect this information.

• Sanction Policy (R) This requirement is directed at our workforce and obliges us to take or invoke appropriate sanctions against anyone who willingly violates our security policies and procedures.

• Information System Activity Review (R) * We must regularly review records of information system activity such as audit logs, access reports, and security incident tracking reports.
  Sygate Technologies, Inc.

• Assigned Security Responsibility (R) 164.308(a)(2) We must assign a person, or persons, to be responsible for the development and implementation of policies and procedures required by the regulation. Workforce Security 164.308(a)(3) We must implement policies and procedures to ensure that those members of our workforce who need access to protected information obtain it and that we deny access to those with no “need to know”.

• Authorization and/or Supervision (A) We must implement procedures to authorize and/or supervise workforce members who work with protected information or might work in a location where they could come into contact with it.

• Workforce Clearance Procedure (A) We must take proactive steps to ensure that the access accorded a workforce member to protected information is appropriate.

• Termination Procedures (A) We must implement procedures for terminating access to protected information when a workforce member leaves our employ or no longer needs access, such as might be the case if they accept another job inside of the organization that does not use the information.

• Information Access Management 164.308(a)(4) We must implement policies and procedures for authorizing access to protected information. This requirement stipulates that our policies and procedures must be internally consistent with the requirements of the broad security rule and its specific parts that deal with access.

• Isolating Healthcare Clearing House Function (R) If we have a healthcare clearinghouse as part of the enterprise then the clearinghouse must implement policies and procedures to protect the electronic protected healthcare information from unauthorized access by the larger organization.

• Access Establishment and Modification (A) This requirement obliges us to “establish, document, review, and modify a user’s right of access” based on our adopted body of policies and procedures.

• Security Awareness and Training 164.308(a)(5) We must implement a security awareness and training program for all workforce employees including management and executives.

• Security Reminders (A) We must provide periodic security updates to our workforce. You may already be doing much of what should be done with publications, logon screen notices etc.

• Protection from Malicious Software (A) * This refers to taking action to detect, guard against, and report software that has as its purpose the destruction of data, communications, or infrastructure that we rely on to conduct business. Normally this would include such things as viruses, worms, and Trojans.

• Login Monitoring (A) * We must take steps to monitor logins and login attempts and report the discrepancies where appropriate.

• Password Management (A) We must take steps to create, change, and safeguard passwords.

• Security Incident Procedures 164.308(a)(6) We must implement policies and procedures to address security incidents. Some of this work could already be being done in the form of policies that deal with the Risk Management Department’s operations and Privacy efforts taken to comply with the Privacy Rule. A normal step that this suggests is that we need to create a security incident response team and insure that it includes other departments such as corporate media, protective services etc.

• Response and Reporting (R) * This specification requires us to identify and respond to suspected or known security incidents; mitigate to the extent practical to minimize damage, and document these incidents and their outcomes.

• Contingency Plan 164.308(a)(7) This requirement is straight-forward: “establish and implement as needed, policies and procedures for responding to an emergency or other occurrence such as fire, vandalism, system failure, or natural disaster that may damage systems containing protected information”.

• Data Backup Plan (R) We must establish and implement procedures to create and maintain retrievable exact copies of electronic protected health information. This also requires that we test to see if we can in fact recover the data from a backed up version at some later date.

• Disaster Recovery Plan (R) We must establish, and implement as needed, procedures to restore any loss of data. By implication this means the systems that process the data or replacement systems if that is appropriate.

• Emergency Mode Operation Plan (R) We must establish and implement, as needed, procedures to enable the continuation of critical business processes for protection of the security of electronic protected health information while operating in emergency mode.

• Testing and Revision Procedures (A) Basically, we have to test and revise our plans on a regular basis to ensure that they work reliably.

• Evaluation (R) * 164.308(a)(8) This part requires us to periodically evaluate and assess both technical and non-technical measures that we take to achieve compliance with the regulation and to be prepared to continue to ensure that we meet the requirements for compliance should changes in our environment occur.

• Business Associate Contracts and Other Arrangements 164.308(b)(1) This section requires that in cases where we have organizations outside of the corporation who create, receive, maintain or transmit electronic protected healthcare information on our behalf, give us satisfactory assurances that they will protect the information in accordance with the requirements in the Final Security Rule. In other words, they are bound by the same standard as we are but do not necessarily have to use the same methods to protect the information.

• Written Contract or Other Arrangement (R) This provision requires us to document arrangements with those who qualify as Business Associates and obliges us to take action if we know that the Associate is not safeguarding the information as agreed to in the contract. The actions that may be/must be taken involve contacting the offending Associate and getting them to fix the problem or, if that fails, terminating the contract with them if feasible, or reporting them to the Secretary of DHHS. The bottom line is that any organization wishing to do business with us that involves protected information must comply with the rule as if they were a covered entity themselves. This part of the Security Rule also applies to their subcontractors, if any, and obliges us to terminate the contract with the Associate if one of their agents or subcontractors violates the Rule and doesn’t return to compliance.

• Facility Access Controls 164.310(a)(1) This portion of the Security Rule requires that we create policies and procedures to limit access to any facility that houses any kind of information system that processes or stores protected information. This includes such things as servers, PCs, terminals or any other computer based device such as the new Computers On Wheels (COWs) that are a part of newer clinical systems that are being fielded. The rule further cautions us to provide for access by those personnel who must have access in order to do their jobs.

• Contingency Operations (A) As part of our required Disaster Recovery Plan and Emergency Mode Operations Plan, we must establish procedures that allow facility access in support of restoration efforts. This part is really focused on ensuring that access controls do not get in the way of getting back into business as soon as possible.

• Facility Security Plan (A) This specification requires that we implement policies & procedures to limit or control access to facilities where protected information is processed on computer and related equipment.

• Access Control and Validation Procedures (A) We must implement procedures to determine someone’s need for access to protected information based on their role or function in the organization. This also applies to any possible access that might be needed to do maintenance or install revisions of the software itself. This portion of the Security Rule specifically includes visitor control, as in the case of outside maintenance personnel.

• Maintenance Records (A) This requires us to implement policies and procedures to document repairs and changes to the physical components of a facility which are related to security. Some examples would include: hardware, walls, doors, and locks.

• Workstation Use (R) 164.310(b) This standard has several pieces; we need to address the following with policies and procedures:
  • Specify the proper functions or uses of a workstation (PC, terminal etc.)
  • Specify how the function will be performed
  • Specify the physical attributes of the area in which the PC or terminal device is located;
  This covers such things as whether or not the PC monitors should face away from personnel who have no need to see the protected information being processed, room should have locking doors, and visitors should be handled.

• Workstation Security (R) 164.310(c) We are required to implement physical safeguards for all workstations that may access protected information and to restrict access to only authorized users.

• Device and Media Controls 164.310(d)(1) We are required to implement policies and procedures that govern the receipt and removal of the hardware and electronic media that contain protected information when it moves into and out of a facility. Further, we have to extend this set of rules to cover the movement of these items within the facility, such as moving PCs from a nursing station on one floor to another floor or clinic area.

• Disposal (R) We must implement policies and procedures to address the final disposition of protected information and the hardware and electronic media (such as floppy disks, CDs, etc.) on which it is stored. This does not mean that we cannot reuse the hardware or media with suitable controls and procedures being in place.

• Media Reuse (R) We can reuse media if we implement policies and procedures that require the removal of any protected information prior to the media being reused elsewhere for some other purpose.

• Accountability (A) We must maintain a record of the movements of hardware and electronic media and any person responsible for them. The “person” in this case could include the person who physically moved the items and the person authorizing the move.

• Data Backup and Storage (A) We must create a retrievable, exact copy of electronic protected health information, when needed, before the movement of equipment. This applies to situations where we move a device with the intention of placing it back into service to continue processing or remove a device from service but still have a need to recover the information that may be stored on it.

• Access Control 164.312(a)(1) This section requires that we implement technical policies (those that can be set in software on a machine for the machine to enforce) to ensure that only those people who are supposed to have access to the software (such as System, Network, and Security Administrators) are allowed such access. This also covers situations where software on a machine needs access rights to other parts of the system or network just as a person would.

• Unique User Identification (R) We must assign a unique name or number to identify a person who has any level of access to our systems and that can be tracked over time.

• Emergency Access Procedure (R) We must establish and implement, as needed, procedures for obtaining necessary protected health information during any emergency.

• Automatic Logoff (A) * Implement electronic procedures that terminate an electronic session after a predetermined time of inactivity. For example, this situation occurs when anyone connected to our network leaves their PC to conduct other business or in situations where staff may go home for the night and forget to log off.

• Encryption and Decryption (A) * We must implement a mechanism to encrypt and decrypt electronic protected health information. This applies to transmitting the protected information to any legitimate person or organization outside of our network.

• Audit Controls (R) * 164.312(b) We must implement hardware, software, and/or procedural mechanisms that record and examine activity in systems that contain or use electronic protected health information.

• Integrity (A) * 164.312(c)(1) We must implement policies and procedures to protect electronic protected health information from improper alteration/destruction.

• Mechanism to Authenticate Electronic Protected Health Information (A) This requirement specifies that we have to take steps to verify that electronic protected health information has not been altered, tampered with, or destroyed in an unauthorized manner.

• Person or Entity Authentication (R) 164.312(d) We must provide a mechanism to verify that the person seeking access to protected information is in fact the person that they claim to be.

• Transmission Security 164.312(e)(1) We must ensure that protected information that travels inside our network or is transmitted to an authorized person or organization outside our network is protected from outside access or intercept.

• Integrity Controls (A) * We must implement measures that ensure that electronically transmitted electronic protected health information is not improperly modified without detection until it reaches its destination and is used as needed.

• Encryption (A) * We must implement a mechanism to encrypt protected information whenever we deem it appropriate. This section of the rule speaks directly to our dealings with Business Associates.

Sygate and HIPAA

Practitioners who truly pay attention to the implied as well as explicit regulatory requirements will quickly realize that only with appropriate technology to complement their efforts will they be able to manage successfully a compliant security program. The primary requirement for any technology solution is that it supports compliance and governance with an ability to continuously adapt, enforce, and maintain an integrated security posture for the
business. A review of available technologies yields a clear choice — the Sygate product suite.

Sygate can give the business the ability to put into place a security framework of continuous compliance that provides a pervasive discovery capability, adaptive security, and an ability to continuously enforce the company’s policies, irrespective of the means of connection to the company's network. The ability to move policy and procedure from written documents to network-enforced mechanisms is a powerful enabler for enterprises, which can be sure, at any time, of their security postures.

This enforcement capability works under all conditions and applies to users inside the organization as well as those connected from outside the network. The Sygate product line is cost-effective and effort-efficient to both manage and maintain. The security practitioner no longer has to depend upon hope or assumptions for reporting on the up-to-the-minute security status of the precious communications means that is the lifeblood of the business.

The rich feature set and broad capabilities, particularly policy enforcement, make the Sygate solution indispensable for dealing with HIPAA security compliance issues, especially those requiring that we maintain positive control over our network. The ability to determine how the network is running and, just as important, what is running on it enables us to evaluate the effectiveness of security measures and contributes to maintaining a sound compliance program.

About the Author:

Gary Swindon, CISM, is the Corporate Information Security Officer for Orlando Regional Healthcare, responsible for all aspects of information security. Orlando Regional Healthcare is a large, private, not-for-profit healthcare organization with 8 hospitals and ancillary clinical activities spread throughout central Florida. Prior to his tenure at Orlando Regional Healthcare, Gary held positions as Principal of his own security consulting practice; Vice President, Chief Security, and Privacy Officer for WebMD Corporation; and Director, Office of Computing and Telecommunications for the State of Michigan. In addition, he spent several years in the Department of Defense as an Intelligence and Security Officer. He has a BA from the University of Dayton and an MBA from Boston University.

Visit the Authors Web Site