13.3 IMPLEMENTING ACCESS CONTROL MECHANISMS ( 164.312(A)(1))

13.3 IMPLEMENTING ACCESS CONTROL MECHANISMS ( § 164.312(A)(1) )

(a)(1) Standard: Access control. Implement technical policies and procedures for electronic information systems that maintain electronic protected health information to allow access only to those persons or software programs that have been granted access rights as specified in § 164.308(a)(4).

The goal of implementing access control mechanisms is to insure that access to information is restricted to only the people that the organization decides should be granted access.

An illustrative analogy is that the computer systems used are a filing cabinet in an office with a guard posted at the door. A number of steps need to be taken in order to secure this filing cabinet.

1. Unique user identification-The guard validates that any person that wants access is who they say they are by checking their identification papers. This verifies that private health is only accessible by those that have been explicitly granted access.

2. Emergency access procedure-If a person needs access to the information due to an emergency, the guard will allow it, but record with a video camera every piece of information that the person looks at and modifies. After the emergency, the video tape will be reviewed to validate that the person adhered emergency data access policies. This allows private health information to be accessed in emergency situations so as to not endanger the health of a patient, while also verifying that appropriate emergency information access policies were followed.

3. Automatic logoff -The guard will make sure that the filing cabinet is closed and locked when the person leaves the office. This verifies that an unauthorized person is not able to take over another person's session to access private health information.

4. Encryption-The filing cabinet will have different keys for different drawers so that only the person can only access appropriate information. The guard will verify that any information that is updated by that person is also signed by that person.

5. Authorization-Who gets which keys for drawers on the filing cabinet is controlled. This validates that only users with explicit access to portions of private health information are allowed to view and update it. This may be as stringent as per patient per user role. For example, a psychotherapist may only have access to a specific patient's therapy record and no other parts of the patient's medical record, while no other users will have any access to the therapy record, or even be aware that it exists.

The reasons for implementing access control mechanism are to make a reasonable effort toward insuring that only the people who are granted access to private health information are the ones that are able to access it.

13.3.1 Unique User Identification (A)(1)(i)

Unique user identification (Required). Assign a unique name and/or number for identifying and tracking user identity.

Before a person is allowed into the room with the filing cabinet, the guard will validate that the person is who they say they are via checking an identification card and asking them for a password before they are allowed to enter the room.

For a computer system in a healthcare organization, this equates to user identification and user authentication. Identification determines who the person is. Authentication verifies that the identification is correct. Many portions of the network should require identification and authentication including applications and the operating system itself.

This most prevalent way to identify a user is via a user login id. It is a built-in feature for almost all applications.

By following a number of guidelines, it is easy to make use login id's resistant to tampering:

1. Require them to be at least 6 characters. The fewer characters in the id, the easier it is for someone to guess one.

2. If they are based on information about the user (such as last name, employee id, etc), combine multiple things to make them hard to guess. For example, combine first initial, last name and employee id.

3. If users share ID's, it makes it impossible to prove who actually accessed an application. This is obviously very important if for example an ordering system is used to schedule administration of a medication that harms a patient. Users will tend to share id for convenience due to not having access to portions of applications under their authorization level and frustration with the time it may take to get a new id added for a new user. To combat this, make a concerted effort to add new identifiers for new users quickly and make sure they get appropriate access to the functionality they need to do their jobs. It is also worth considering configuring applications to alert an administrator or deny access if the same id is used to access an application concurrently.

4. Create a policy for disabling user id's that are no longer valid such as when and employee leaves an organization. Ids for temporary users such as contractors and interns should be configured to be automatically disabled at a future date. There are many cases of users accessing applications long after their right to use them has expired .

5. Not all users will use all applications that they are given access to. This creates an opening for malicious users to misuse applications. To ensure 'minimal necessary' requirement, configure all applications to disable accounts that are not active for a certain number of days (such as 90).

13.3.2 Emergency Access Procedure (A)(1)(ii)

(ii) Emergency access procedure (Required). Establish (and implement as needed) procedures for obtaining necessary electronic protected health information during an emergency.

To continue the previous analogy, if the person claims an emergency situation, the guard will verify who the person is and let them into the filing cabinet. The person will be temporarily supplied all keys needed to view any information in the cabinet. Additionally, the guard will record every piece of information viewed and modified in the cabinet. After the emergency is over, this log will be reviewed against policy of what information may be accessed in an emergency situation.

In a healthcare environment, it is not possible to require that appropriate security procedures and enforcements are followed during emergency situations, such as when a patient is in dire need of a medication and the user authenticated with the computer system used to dispense the medication does not have authorization for that functionality.

A basis for HIPAA is to ensure privacy, integrity, security and confidentiality for electronic Patient Health Information. The Emergency Access safeguard looks at Disaster Recovery (DR) and Emergency access to PHI.

One approach to DR can be addressed with the following key objectives in mind:

1. Identify critical EPHI applications.

   • What applications are being used to retrieve patient records throughout the workflow?

2. Rank EPHI applications according to priority for recovery.

   • What critical applications are required for minimal operations to maintain business continuity (what needs to happen first, mainframe access to patient records, or electronic mail)?

3. Define the maximum acceptable amount of outage or downtime for each application

   • How long can the hospital function, without being able to verify Emergency Room patient data?

4. Back up critical applications, EPHI data, and operating systems and establish and acceptable backup methodology with restoration timeframes as a leading factor

   • Are the entire data sets being archived in the event of a fire, so that they can be quickly retrieved and restored in a timely fashion?

5. Identify alternative operations facilities for critical systems and determine site location based on risks (i.e. Natural disasters, terrorism, access to facility etc)

   • Is the disaster recovery facility displaced regionally in comparison to the location of the current operations facility to ensure a disaster cannot affect both the primary and alternate sites?

6. Develop disaster recovery site procedures.

   • Develop scheme for acquisition of recovery data (who has access, where is it kept, how does it get to the alternate site

   • Develop documentation and procedures for rebuilding critical systems (this includes network, server, mainframe reconstruction)

   • Identify disaster recovery teams and phone #s

   • Test access, authorization and auditing to ensure compliance remains constant with that of normal operations

   • Test the disaster recovery plan

   • Is the plan developed, documented and tested on an ongoing basis?

7. Based upon changing environments and testing, update procedures and documentation

   • If new technologies have been introduced into the equation since the last test, does the documented plan reflect that?

Emergency access to EPHI is required when non-standard access must be granted in order to retrieve EPHI. This type of access is an exception to the rule and must be handled diligently. Special access may be granted for Emergencies under the following guidelines:

1. Users are identified, authorized and authenticated prior to granting emergency access

   • Who are you? Why do you require this access? Prove you are who you claim to be

2. User access is audited and monitored during the entire process and is reviewed with utmost scrutiny to ensure HIPAA techniques are maintained

   • What was accessed? Why was it accessed? Was it based on 'need to know' information?

13.3.3 Automatic Logoff (A)(1)(iii)

(iii) Automatic logoff (Addressable). Implement electronic procedures that terminate an electronic session after a predetermined time of inactivity.

Automatic logoff is required to make sure that unauthorized users do not recycle existing sessions if a user leaves a workstation. An analogy for this is the guard verifying that the filing cabinet is relocked after every use.

The most common way to implement this is to set timeouts on all applications so that if they are idle for a period of time, the session is automatically closed. Many organizations implement this via setting different idle times in different applications (based on the type of application and where it is used) and in the operating system itself. At a minimum, workstations should lock the screen after a certain number of minutes of idle time. If the workstation becomes locked, the applications on those workstations cannot be accessed.

There are other methods for performing automatic logoff that involve other ways to detect an unattended workstation. These include proximity devices that detect if a person is in front of the computer via motion sensors and identification devices that can actively poll to see if the user is still at the workstation (such as RF devices and facial biometrics).

13.3.4 Encryption and Digital Signatures (A)(1)(iv)

(iv) Encryption and decryption (Addressable). Implement a mechanism to encrypt and decrypt electronic protected health information and user credentials both in traffic and storage. Storage mechanisms should not be susceptible to tampering, altering or viewing.

Encryption technologies are used to make sure that confidential information (such as patient information and authorization codes) are not accessible by entities that are not authorized to use it. An analogy to encryption is having a key for each drawer in the filing cabinet. Only those with the key can view this information. Digital signatures are used to validate the source of data (such as which physician signed an order) and to validate that data was not modified (such as security audit logs). An analogy to digital signatures is requiring every person who modifies a file to sign it with each modification.

Protocols that contain confidential information that are not encrypted should be avoided on the internal network and prohibited on the external network. This includes:

• Remote access from users should be either an encrypted VPN connection or encrypted web protocol (HTTPS).

• All web applications should be configured to expire cached pages in order to make sure that saved private health information is not compromised on public terminals.

• No e- mails should be sent with private health information unless they are encrypted.

• No protocols should be used that send authorization information in an unencrypted manner on either the internal or external network (use secure copy SCP instead of file transfer protocol FTP. Use Secure Shell (SSH) instead of telnet.) This should be prohibited on the internal network as well as external because it allows user authentication to be subverted.

All critical information should be digitally signed when written to insure that 1. The signer can be verified and 2.The data has not been modified.

13.3.5 Authorization Methodologies

Even though the Security Rule does not include a specific specification for authorization, it is a necessary component of any access control system. Moreover, proper implementation of authorization mechanisms is required in order to support certain Privacy Rule's requirements (like Use and Disclosure ).

Presently, there exist two main methodologies for controlling access- Discretional Access Control (DAC), and Mandatory Access Control (MAC), discussed in greater details in the following sections. The main difference between those methods lies in the abilities to change access control to objects, and, thus, their ownership. DAC model allows a subject (computer user, for instance) to grant access, at his discretion, to the objects or resources that he owns or accesses to other subjects-hence discretional. In other words, he is capable of transferring part of his authority to others. MAC model, on the other hand, implies that all data belongs to the organization, and, while a subject may be allowed certain operations on objects, it is not possible for him to grant access to these objects to other users.

13.3.5.1 Discretional Access Control (DAC)

Definition of DAC:

A means of restricting access to objects based on the identity of subjects and/or groups to which they belong. The controls are discretionary in the sense that a subject with certain access permission is capable of passing that permission (perhaps indirectly) on to any other subject (unless restrained by mandatory access control).

Trusted Computer Security Evaluation Criteria, DOD 5200.28-STD. Department of Defense, 1985.

This methodology is based on a decentralized data ownership model, where individual subjects can own objects, and make changes to their access policy, in effect, delegating part of their authority to others. This model forms a Single Level Security system, which assumes the same level of trust for all subjects. Each object has so called Access Control List (ACL), which is consulted when a subject requests access to the object. The ACL enumerates operations that each specified user is allowed to do on the object-this decision is based both on the user's identity and his group memberships.

A standard Unix or Windows file system can serve as an example of a DAC model-as a file is created by a user, the creator can change its access mode and privileges at his own discretion, for instance, by granting another user privileges to read and modify the file.

One of the primary requirements of HIPAA is existence of and adherence to an adequate security policy, which, among other things, is designed for protection of EPHI. In healthcare industry, the data is not owned by the individual employees , but, rather, by the organization itself- because it is the organization that carries the ultimate responsibilities for its protection. However, when individual users are allowed to change resource access privileges outside of the administrator's control, it is very hard, virtually impossible to implement a reasonable organization-wide access policy. Actually, DAC-based policy implementations do exist, but the maintenance burden is very high and not acceptable in most cases.

13.3.5.2 Mandatory Access Control (MAC)

Definition of MAC:

A means of restricting access to objects based on the sensitivity (as represented by a label) of the information contained in the objects and the formal authorization (i.e. clearance) of subjects to access information of such sensitivity.

Trusted Computer Security Evaluation Criteria, DOD 5200.28-STD. Department of Defense, 1985.

The MAC approach operates on the assumption that resource ownership is centralized, and, thus, must be protected by a centralized authority. It introduces the concept of Multi Level Security (MLS) system, where there is a hierarchy of trust within the system. MAC is based on assigning classification to each object (document, resource), while each subject (user, process, etc.) gets its clearance. Both classification and clearance structures are hierarchical, i.e. each following level is more trusted than the previous one. For example, US military defines sensitivity levels (in increasing importance): unclassified, confidential, secret, top secret, and clearances, matching military ranks, to name a few: private, lieutenant, major, general. Each subject is expected to perform a single duty, which is assigned a certain clearance. The administrator ties clearances to classifications by configuring the system, as defined by the organization's security policy, and the system itself enforces access control. The subject has no influence over the outcome of the decision-hence 'mandatory access control'. In order to gain access, the subject's clearance must at least equal, or exceed the requested object's classification. The assumption is that object's importance directly (1-to-1) translates into the classification, and all objects with similar (or lower) sensitivity settings can be viewed by the same audience (subjects with appropriate clearances), and, conversely, each subject is entitled to view all documents of same or lower sensitivity.

There exists a more sophisticated version of MAC, using security labels, that combines classifications and categories. These categories are not hierarchical, and they provide a way to specify an additional set of restrictions, orthogonal to classification.

Further refinements to this model are required when more fine-grained access decisions are needed, like differentiating different access types: read and update. Bell-LaPadula, Bibi, and Clark-Wilson models provide additional restrictions to the methodology to preserve confidentiality and integrity of the objects.

The upside of this methodology lies in the administration simplicity-in a straightforward MAC implementation, there is only a single assignment per subject or object that needs to occur, and it is completely centralized. It works well within structured organizations with rigid hierarchies, where people perform the same duties for years . Unfortunately, this model starts failing miserably as soon as it is confronted with multiple roles per subject, multiple types of objects, further refinements of access control, or when personnel frequently changes assignments or responsibilities.

While the original MAC model does not serve the needs of healthcare industry too well because of its lack of flexibility, several other models have emerged lately. They are based on the MAC's principle of central ownership of protected resources, but provide significant improvements in terms of user access management.

13.3.5.2.1 Role Based Access Control

Role-Based access control (RBAC) model was developed in 1970s together with relational databases, and formalized by NIST, which holds the corresponding patent. RBAC is an extension of MAC in that it treats all data as centrally owned, subjects can not share any of their authority with others, and the system enforces the specified access policy. Users access control capabilities are determined by their roles within the organization, or, rather, their mapping of those roles to the system-defined ones. As opposed to MAC, these roles are not hierarchical, i.e. a user, highly privileged in one domain, might have no authority and resource access in another domain. To implement finer-grained scenarios, the roles may form hierarchies with multiple roots, with derived roles inheriting and extending privileges of their 'parents'. Individual users may have multiple roles assigned to them, combining access privileges granted both to those roles and to the user itself.

Relational databases and Java Authentication and Authorization Service (JAAS) provide real-world examples of RBAC implementations.

RBAC has enjoyed good acceptance in the healthcare community, especially since it has been formalized in the beginning of 1990s. The centralized data ownership caters well to the needs of policy implementation, yet RBAC provides flexible enough approach to allow personnel role assignments.

13.3.5.2.2 Context Based Access Control

The shortcomings of RBAC model start coming out in collaborative environments, also very common in healthcare industry. When the pure role-based system is faced with the task of making access control decisions, based not only on the roles, but also on transient parameters, which must be re-evaluated with every access, its maintenance becomes burdensome.

An example of such a situation is a group of medical providers, where only the doctor Y would normally have full access to the record of patient Z. but he wants to delegate the case to the specialist X. In order for the specialist to access the record, X must be granted access to it, but this access should not be full (i.e. only add, never delete or update existing information), and time-based (on 'minimal necessary' basis). While it is possible to implement these types of relationships using traditional RBAC, another model has been developed, which extends RBAC to address precisely such conditions.

This model is known as Rule Based Access Control (or, alternatively, Policy-based), and is the most flexible of all outlined approaches. Authorization here is based on the outcome of normal RBAC access checks, as well as runtime evaluation of the rules, implementing stated policies and procedures. The rules are set by the administrator, and they still match the pre-defined policy, but allow, within the boundaries of that policy, to define additional types of non-contradictory rules, which are going to be evaluated upon each access request. The main advantage in this implementation is that there is no need to invent artificial or temporary roles that need to be disabled at a particular time. The downside of this methodology is more complicated configuration, introduced by evaluating run-time policies. However, this configuration is well-defined and structured, as opposed to adding chaotic set of temporary roles addressing shortcomings of the traditional RBAC.

In the earlier example, a time-based rule might be added to the system stating that the specialist X has access to the Z's record only until the following Friday, and another rule would specify that he is granted only 'add' privilege on that record, but not 'update' or 'delete'.

Presently, there are many rule engines on the market, commercial as well as open source.

13.3.5.3 Summary of Authorization Approaches

Name	Ease of Implementing	Ease of Maintaining	Centralized Protection	Flexibility
DAC	Good: most systems require little initial setup	Fair: setups are easily modifiable for individual users	Poor: Does not allow central control of data	Good: allows a lot of flexibility for individuals
MAC	Excellent: requires very limited setup	Excellent: users' setups are centrally modifiable	Excellent: full central control of data	Poor: very rigid rights assignments
MAC: RBAC	Good: requires setting up user role hierarchies	Good: definitions of roles and user memberships are centrally located	Excellent: full central control of data	Good: allows a lot of flexibility in static cases
MAC: policy-based	Fair: requires developing and implementing role hierarchies and policies	Fair: definitions or roles, user membership, and policies are centrally located	Excellent: full central control of data	Excellent: support for both static and dynamic modifications