Break glass (which draws its name from breaking the glass to pull a fire alarm) refers to a quick means for a person who does not have access privileges to certain information to gain access when necessary. Systems containing primary source data (information) for treatment, must develop, document, implement and test break glass procedures that would be used in the event of an emergency requiring access to ePHI. These systems must have a clearly stated and widely understood procedure for allowing access via alternate and/or manual methods.
The system administrator should document any actual emergency access for later audit & review. Typically, a special audit trail is created to monitor such access. Standard access controls should be established with sufficient rules to minimize the number of times break–the–glass needs to occur.
Break–glass is based upon pre–staged “emergency” user accounts, managed in a way that can make them available with reasonable administrative overhead. This solution can be used with a broad range of existing systems and architectures that require operators to login, such as with username and password, before access is granted. The break–glass intended to specifically cover emergency cases and should not be used as a replacement for a helpdesk.
User authentication system is a typical mechanism used to control and monitor access to sensitive data. It is designed to preserve security by restricting access. In clinical care, a delay in access is likely to disrupt patient care that may cause patient discomfort, injury or worse. For this reason HIPAA requires covered entities to have mechanisms in place that assure patient care is not impaired by problems with the user identification and authentication.
Scope
An emergency access solution should be used only when normal processes are insufficient (e.g. the helpdesk or system administrator is unavailable). Examples of situations when ‘break glass’ emergency access might be necessary:
- Account problems:
- Forgotten Username/Password (e.g. after extended absence or vacation)
- Locked Password (e.g. mis–typed too many times)
- No User Account (e.g. a clinician from another organization or a new clinician is assisting a facility during an emergency)
- Authentication problems:
- Central Authentication System failure (e.g. a CAS server is down)
- Smart Card or biometrics reader failure (e.g. reader or biometric is damaged)
Note: In cases where the authentication system fails, there should be an alternate authentication mechanism such as username/password.
- Authorization problems:
- An emergency medical situation thrusts an individual into a role where s/he lacks sufficient access rights (e.g. an administrative assistant is entering orders during an emergency)
Break Glass solution
The break–glass solution is based on pre–staged emergency user accounts, managed and distributed in a way that can make them quickly available without unreasonable administrative delay. This solution should be simple, effective, and reliable.
Pre-staging Accounts
Emergency Accounts should be created in advance to allow careful thought to go into the access controls and audit trails associated with them. The following factors should be considered:
- Username should be obvious and meaningful, such as breakglass01, so the account name would be inappropriate under normal operations and would stand out in audit trails.
- Strong passwords should implemented, but is important, that they not be so difficult that in an emergency, the user would have trouble entering it.
- Account Permissions should be set to minimum necessary privilege. Limit emergency access to the minimum data and functionality needed to perform the task. This could potentially include view–only capability, prohibiting access from outside the local console or network, limiting to data acquisition only, or prohibiting access to previously acquired data, but due to the difficulty of anticipating emergency needs, you may choose to allow full access to emergency accounts.
- Auditing should be enabled if available, to log details of the account usage and details of the work carried out while using the account. Some systems may recognize emergency accounts and raise the system auditing level or increase audit logging of only the emergency accounts.
Note: Ensure that the individuals who create the accounts are not the ones reviewing the audit trails since this can be a source of abuse.
The ‘break glass’ accounts and distribution procedures should be documented and tested as part of implementation.
Distributing Accounts
Pre–staged accounts need to be carefully managed to provide timely access when needed. Break–glass requires that the emergency–account details be made available in an appropriate and reasonable manner. These details may be provided on media such as a printed page, a magnetic–stripe card, a smart card or a token. Some distribution possibilities for break–glass emergency accounts include the following:
- Kept behind glass in a cabinet, where access to the accounts requires literally breaking the glass (similar to a fire extinguisher or alarm), providing an obvious indication that the accounts have been accessed and a deterrent to casual use;
- Maintained within sealed envelopes, where a broken seal would be an obvious indication that the accounts have been accessed;
- Locked in a desk drawer that only specific people can access;
- Sealed and taped to the side of a monitor in a clinical area—visible to many so it will be obvious when it is missing or damaged, or
- For cases where more than one person is needed to declare an emergency, locked in a safe or cabinet where one person knows the combination or has the cabinet key and a different person has the key to the room.
A best–practice would place the pre–staged emergency accounts into the responsible care of an individual. This Emergency Account Manager would be someone readily available during operating hours and one who understands the sensitivity and priority of the emergency accounts (e.g. a business manager, charge nurse or security officer). The distribution procedure would include a sign–out method requiring that an acceptable form of identification be provided. This identity would be recorded before the accounts are made available. Following such a procedure assures that activities performed using the emergency account may eventually be associated with an authorized individual, creates accountability and can assure non–repudiation.
Monitoring Use of Accounts
The use of emergency accounts needs to be carefully monitored. The audit mechanisms should be used and a procedure defined to examine the security audit trails on a regular basis to identify any use of the emergency accounts. In addition, systems can alert the security administrator in the event an emergency account is activated. These enhanced capabilities are highly desirable, but they are not required for the break–glass mechanism to work. If the system or application software cannot provide an audit trail that shows simple account activity like login attempts, then the use of break–glass needs to be carefully considered before implementing. Break–glass may still remain a valid system, but it will require the use of a manual (e.g. paper–ink) log.
Documentation should describe the intended use of such accounts and the consequences of their inappropriate use. Details should be clearly documented and then communicated to the relevant workforce. It should be clear that all use of emergency accounts is closely monitored. A periodic review and retraining of staff should be done to make sure the break–glass procedure continues to be relevant.
Each use of an emergency account should be reviewed. The use of an emergency account may be valid, or it might indicate a malicious act. Unacceptable use needs to be recorded and acted upon. Frequent use may indicate problems with the normal user authentication mechanism. This regular monitoring of pre–staged emergency accounts should also include exercising some of them to ensure that they do work, and that their use can be detected. This is similar to testing fire alarms, to be sure that they will work in a real emergency.
Cleaning Up After Account Usage
A procedure should be established to clean up after an emergency account has been used. Consider addressing the following:
- Disable or delete the emergency account(s) that were used to prevent re–use now that the password is known. Some systems may be capable of automatically deactivating emergency accounts after first use or passage of a selectable period such as 8 hours or 1 day. Avoid disabling the account during the period of emergency use.
- Reconcile the data acquired and audit trails to reflect the proper operator’s name.
- Make entries in disclosures if appropriate (see HIPAA 5003 policy, procedure and forms).
- Review activities performed including data acquired/accessed
- Determine if the emergency account procedure and operation worked effectively and adjust if necessary
Reference: This documentation was written using text from a whitepaper developed by the Joint NEMA/COCIR/JIRA Security and Privacy Committee (SPC) – December 2004.