Is Your Application HIPAA-Compliant?

Introduction

Software applications meant to handle or host protected health information (PHI) must comply with the HIPAA Security Rule.

I read an article recently where the author reported that hospitals were seeking the “killer” Amazon Alexa app. A teaser in the article stated “The only problem with Amazon Alexa in health care? It's not HIPAA-compliant.” According to the article, hospitals are tinkering with Alexa apps for things like safety checklists, documentation and transcription.

If you’re not familiar with Amazon’s Echo and other Alexa devices, they are listening devices connected to the Internet that employ voice recognition technology. Per Amazon.com, they let you instantly connect to Alexa to play music, control your smart home, get information, news, weather, and more using just your voice.

The privacy implications aside, if hospitals are considering Amazon Alexa apps, it is probably a good time again to remind everyone (especially software developers of healthcare applications) what “HIPAA-compliant” means in terms of application software.

This is my attempt to outline what auditors need and would like to see in HIPAA-compliant applications:

What functionality does HIPAA clearly require of an application that handles ePHI?

What does HIPAA infer should exist?

And lastly, what other security-related functionality should the application include to make it more auditor-friendly?

HIPAA Application Security Requirements and Best Practices

HIPAA's application security requirements as well as optional but recommended “best practices” are categorized under the HIPAA Security Rule sections from which they originate.

1.0 Risk Analysis

HIPAA Requirement

§164.308 Administrative Safeguards—

§164.308(a)(1)(i) Standard: Security management process. Implement policies and procedures to prevent, detect, contain and correct security violations.

§164.308(a)(1)(ii)(A) Implementation specifications: Risk analysis (Required). Conduct an accurate and thorough assessment of the potential risks and vulnerabilities to the confidentiality, integrity and availability of electronic protected health information held by the covered entity or business associate.

§164.308(a)(1)(ii)(B) Implementation specifications: Risk management (Required). Implement security measures sufficient to reduce risks and vulnerabilities to a reasonable and appropriate level to comply with §164.306(a).

Analyze Application Security Risks

Developing or acquiring application software that meets all of the HIPAA security requirements can reduce the level of effort required to complete the security risk analysis as well as avoid documentation burdens. When an “addressable” HIPAA implementation specification is not met (e.g., due to missing application functionality), the organization must perform an assessment to determine whether the specification is a reasonable and appropriate safeguard in the covered entity’s environment, and document these assessments and all decisions. The outcome of the security risk analysis process is a critical factor in assessing whether an implementation specification or an equivalent measure is reasonable and appropriate.

Organizations must be aware of the specific risks to their information, customers and assets in order to select appropriate risk management strategies that mitigate risks to acceptable levels. HIPAA’s “Risk Analysis” implementation specification requires conduct of a security risk analysis of the potential risks and vulnerabilities to the confidentiality, integrity, and availability of ePHI held by the covered entity.

Minimize the ePHI “Footprint” Subject to HIPAA

The scope of the risk analysis should include all ePHI applications, the underlying IT infrastructure, and the business processes which use the applications and therefore touch ePHI. Where possible, minimize the number of applications and related IT infrastructure containing ePHI and segment ePHI within the application modules to reduce the opportunities to inappropriately view or update ePHI. This will minimize compliance effort by minimizing the footprint of the ePHI environment.

2.0 Information Access Management

HIPAA Requirement

§164.308 Administrative Safeguards—

§164.308(a)(4)(i) Standard: Information access management. Implement policies and procedures for authorizing access to electronic protected health information that are consistent with the applicable requirements of subpart E [Subpart E—Privacy of Individually Identifiable Health Information] of this part.

§164.308(a)(4)(ii)(B) Implementation specifications: Access authorization (Addressable). Implement policies and procedures for granting access to electronic protected health information, for example, through access to a workstation, transaction, program, process or other mechanism.

§164.308(a)(4)(ii)(C) Implementation specifications: Access establishment and modification (Addressable). Implement policies and procedures that, based upon the covered entity's or the business associate's access authorization policies, establish, document, review and modify a user's right of access to a workstation, transaction, program or process.

Authenticate Users and Authorize User Access

Access to sensitive information and functions within applications must be controlled through the use of authentication and authorization systems. Generally speaking, such systems must be capable of validating at least one factor of user identity (such as a username and password) and implementing restrictions on use compliant with the HIPAA Privacy Rule's "minimum necessary" requirements (i.e., least-possible privilege). Care must also be taken to secure authentication data throughout its life cycle to prevent unauthorized interception and use.

The Information Access Management standard infers that application security functionality provide the capability to create, modify and deactivate or remove user accounts. Two of the implementation specifications under this standard – “Access Authorization” and “Access Establishment and Modification” – infer that an ePHI application should have user authentication and authorization capabilities, unless the organization concludes that it is not a reasonable and appropriate safeguard in its environment, when analyzed with reference to the likely contribution to protecting the entity's ePHI.

ePHI applications must employ authentication mechanisms capable of validating user identity prior to the user accessing application resources (authentication). ePHI applications should also be capable of assigning user rights and privileges that are aligned to sensitive functions (authorization), and restrict the user's access to the minimum necessary application functionality, resources and data they need to perform their duties.

While HIPAA does not mandate role-based access control or “RBAC” functionality, implementing such a structure between users and detailed permissions contributes to the efficient administration of user access.

Furthermore, assigning users to roles is preferable to setting up new users via “cloning” as the latter, over time, tends to result in excessive access to sensitive information.

Optional

Consider deploying these additional application security capabilities:

Deny All—Automatically assign "deny all" rights to a user account until rights are formally assigned.

Security Reporting—Develop reports for administrators and auditors to enable them to: a) list all users, user account status and the date of the user’s last access; b) list all roles and their underlying permissions; and c) list each user's access and capabilities.

Encryption of Credentials—Encrypt authentication credentials transported over networks, whether internal or external, as well as in storage.

Two-Factor Authentication—Authenticate administrator-level users using at least two factors of identity, as deemed appropriate by risk.

One-Time Passwords—Set initial passwords, or those being reset, to a unique one-time password that must itself be reset after the first use.

The importance of security reporting cannot be overemphasized. It is surprising to us as auditors how frequently clients must provide audit evidence as screen shots because the application developers did not include a simple report. Ideally, provide the ability to extract such list-based information to a format that is compatible with Microsoft Excel.

3.0 Protection from Malicious Software

HIPAA Requirement

§164.308 Administrative Safeguards—

§164.308(a)(5)(i) Standard: Security awareness and training. Implement a security awareness and training program for all members of its workforce (including management).

§164.308(a)(5)(ii)(B) Implementation specifications: Protection from malicious software (Addressable). Implement procedures for guarding against, detecting and reporting malicious software.

Fortify Applications for Insecure Networks

The organization should ensure a secure network configuration has been deployed to protect the transmission and storage of sensitive information. HIPAA’s “Protection from Malicious Software” implementation specification under the “Security Awareness and Training” standard requires the implementation of procedures for guarding against, detecting and reporting malicious software, unless the organization concludes that it is not a reasonable and appropriate safeguard in its environment, when analyzed with reference to the likely contribution to protecting the entity's ePHI. Secure networks have the effect of thwarting malicious software; however, applications should be fortified against weak network security.

Implement Secure Application Code

The organization should ensure that consistent and repeatable systems development practices are in place to control the creation and addition of application systems. HIPAA’s “Protection from Malicious Software” implementation specification under the “Security Awareness and Training” standard requires the implementation of procedures for guarding against, detecting and reporting malicious software, unless the organization concludes that it is not a reasonable and appropriate safeguard in its environment, when analyzed with reference to the likely contribution to protecting the entity's ePHI. While HIPAA does not mandate secure systems development practices, such practices improve the security of sensitive information as they have the effect of thwarting malicious software.

Optional

Consider deploying these application security capabilities:

Avoid Insecure Services—Avoid using insecure, poor or risky protocols such as FTP, TELNET and unencrypted TCP sockets in the application. Such protocols do not protect sensitive information, including login credentials, from eavesdropping.

Web Application Firewall—Embed automated tools in the application to filter and screen all web application input and output. These tools should be capable of detecting and/or preventing exploitation of known coding vulnerabilities, blocking unwanted or malicious input and screening the web application from known application-layer attacks.

De-Identify Test Data—If the restriction and/or prohibition of the use of a copy of production data within test/development environments is not considered feasible, implement an application data export feature that de-identifies the copy of production data making it suitable for export to the test environment. Proper de-identification of ePHI renders it no longer subject to HIPAA.

Information Remnants—Ensure that technical and functional designs safely eliminate all information systems remnants when no longer required by a calling process. This includes monitoring and managing physical and virtual memory stores, files and other areas that can inadvertently store temporary data.

Coding Practices—Employ application software coding practices that prevent or detect certain application security weaknesses such as those maintained by the

Open Web Application Security Project (OWASP) in their “OWASP Top Ten” list (See owasp.org).

4.0 Password Management

HIPAA Requirement

§164.308 Administrative Safeguards—

§164.308(a)(5)(i) Standard: Security awareness and training. Implement a security awareness and training program for all members of its workforce (including management).

§164.308(a)(5)(ii)(D) Implementation specifications: Password management (Addressable). Implement procedures for creating, changing and safeguarding passwords.

Fortify Safeguards over Users Accounts—Password Policies

When using password authentication, special controls must be implemented to prevent application security compromises due to weak password policies. Organizations must be diligent in protecting user accounts against brute-force and dictionary attacks on passwords by implementing strong password management processes, such as password length and complexity, account lockouts and automatic session timeouts.

HIPAA’s “Password Management” implementation specification requires procedures for creating, changing and safeguarding passwords, unless the organization concludes that it is not a reasonable and appropriate safeguard in its environment, when analyzed with reference to the likely contribution to protecting the entity's ePHI.

Application security functionality should include password management features or the option to integrate the application’s security with an LDAP product such as Microsoft’s Active Directory. Although not enumerated in HIPAA’s details, password management features of high value include, among others, the capability to enforce:

Password Rotation—User must change their password after “n” days.

Password Length—User must create a password of not less than “n” characters.

Password Complexity—User must compose a password that is not simple or easy to guess.

Password History—User must create a password different from the last “n” passwords.

Prohibited Passwords—User must create a password different from any on the prohibited list.

Optional

Users should create their own password rather than receiving a password created by the application or by another person. Users are more likely to remember passwords they create without writing them down. Alternatively, users may generate and store a strong password using their password safe software.

5.0 Unique User Identification

HIPAA Requirement

§164.312 Technical Safeguards—

§164.312(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) [authorized].

§164.312(a)(2)(i) Implementation specifications: Unique user identification (Required). Assign a unique name and/or number for identifying and tracking user identity.

Enforce Accountable Access to ePHI

Organizations must implement strong user account management processes to maintain the validity of application access lists and prevent access to sensitive information by unauthorized individuals. These processes seek to ensure that the “minimum necessary,” "business need-to-know" and "least possible privilege" principles are rigorously observed.

HIPAA’s “Unique User Identification” implementation specification requires assignment of a unique username to each user for purposes of identifying and tracking user activity. The application should employ usernames for all users and disallow the existence of duplicate usernames, as they defeat individual accountability.

Optional

Consider deploying these additional application security capabilities:

System/Application ID Flag—For system IDs and application IDs not meant to be used by users, enable the system/application ID to be flagged as such in the application; restrict their use to the operating system level if possible (i.e., users should not be able to log in to the application using system/application IDs); and automatically log all use.

System Use Notification—Display a message to all application users with information in the message similar to the following:

Identify the application being accessed;

State that all activities in the application may be monitored and recorded;

Outline penalties for unauthorized use of the application; and

Clarify that use of the application implies consent to monitoring and recording.

Time-of-Day Restrictions—Restrict user access to the application based upon time-of-day, where justified by risk.

Control ePHI Export or Download—Establish access control over of application functionality that allows export or download of ePHI to local storage or external media. Ensure that all exporting or downloading of ePHI is a logged activity.

6.0 Automatic Logoff

HIPAA Requirement

§164.312 Technical Safeguards—

§164.312(a)(2)(iii) Implementation specifications: Automatic logoff (Addressable). Implement electronic procedures that terminate an electronic session after a predetermined time of inactivity.

Fortify Safeguards Over User Accounts—Automatic Logoff/Session Lock

HIPAA’s “Automatic Logoff” implementation specification requires the implementation of electronic procedures that automatically terminate an electronic session after a predetermined time of inactivity, unless the organization concludes that it is not a reasonable and appropriate safeguard in its environment, when analyzed with reference to the likely contribution to protecting the entity's ePHI. Any session left idle for more than “n” minutes automatically expires and the user is forced to re-enter their password to resume their session.

Optional

Consider deploying these additional application security capabilities:

Device-Specific Configuration—Enable the administrator to configure the period of inactivity by type of device—workstation, laptop, tablet PC, smart phone, etc. —that the application supports. The more portable the device, the shorter the allowable period of inactivity should be.

Account Lock—Automatically disable a user’s account after “n” failed login attempts, and automatically enable the user’s account that has been locked-out due to security violations after a minimum period of “n” minutes or when manually reactivated by a security administrator.

Concurrent Session—Automatically limit the number of simultaneous sessions a user may sustain within the application. This discourages credential sharing and ultimately forces users to obtain and use their own username and password.

Last Login Notification—Display a message to users upon successful login indicating information about user account activity, such as the time of the last successful login and the number of unsuccessful logins since last login. Such information enables users to detect unauthorized access to their account.

Inactivate User Accounts – Automatically disable application user accounts that meet certain conditions. Criteria for consideration may include:

Accounts inactive for a preset period of time (e.g., 45 days, 90 days, etc.).

Accounts of non-employees (e.g., contractors, consultants, etc.) after a preset period of time (e.g., contract duration, 90 days, etc.).

Accounts of employees terminated or end-dated in the Human Resources application.

As noted previously, the password should be encrypted in storage.

7.0 Encryption and Decryption

HIPAA Requirement

§164.312 Technical Safeguards—

§164.312(a)(2)(iv) Implementation specifications: Encryption and decryption (Addressable). Implement a mechanism to encrypt and decrypt electronic protected health information.

Encrypt ePHI in Storage and Protect its Integrity

As justified by risk, the organization should implement effective cryptography technologies to ensure the continued integrity and confidentiality of its sensitive information.

HIPAA’s “Encryption and Decryption” implementation specification under the “Access Control” standard requires the implementation of a method to encrypt and decrypt ePHI in storage, unless the organization concludes that it is not a reasonable and appropriate safeguard in its environment, when analyzed with reference to the likely contribution to protecting the entity's ePHI.

Implement strong, industry-acceptable cryptographic algorithms and associated key management procedures to encrypt stored electronic data at rest that is sensitive. If cryptographic controls cannot be leveraged, employ other electronic mechanisms to corroborate that ePHI has not been altered or destroyed in an unauthorized manner. Such mechanisms may include the use of digitally signed records or the use of record-level hash or control totals to detect integrity issues. Ideally, such integrity-checking controls would detect a change to ePHI made outside the application, whether or not intentional.

8.0 Audit Controls

HIPAA Requirement

§164.312 Technical Safeguards—

§164.312(b) Standard: Audit controls. Implement hardware, software and/or procedural mechanisms that record and examine activity in information systems that contain or use electronic protected health information.

Create Audit Trails

The organization should deploy controls that can identify and record security events on its applications containing sensitive information. Management should identify the scope of its monitoring program (specifically addressing its network, system, application and file assets) based on the sensitivity of and risks to the information. Once deployed, these controls should be capable of generating comprehensive audit trails for all accesses and operations performed on sensitive information.

Record Access to Systems by Users and Programs

HIPAA’s “Information System Activity Review” implementation specification requires the implementation of procedures to regularly review records of information system activity, such as audit logs, access reports, and security incident tracking reports. Applications must capture information system activity as well as be capable of reporting the activity for periodic review purposes. Event capturing systems must be in place to record all successful and failed access attempts to the application by user and program accounts. Access to any system utility that possesses the ability to modify sensitive data should also be monitored. Provide reports of information system activity (e.g., failed login attempts, application alerts, etc.) sufficient to support regular review.

HIPAA’s “Audit Controls” standard requires the implementation of hardware, software and/or procedural mechanisms that record and examine activity in information systems that contain or use ePHI. Event capturing systems must be capable of recording the modification of stored sensitive data as well as all individual accesses to sensitive data, even if the sensitive data was not modified. Provide reports and alerting of activity related to ePHI, including accesses, updates and deletes as well as unusual activity in the application such as failed login attempts, abnormal volume of accesses to ePHI and log tampering, among others.

Optional

Consider deploying these application security capabilities:

Record Actions Performed under Administrator Accounts—Record all actions performed by accounts with administrative privileges over the application.

Fault Logging and Integrity Errors—Record all events encountered during data operations that may indicate application faults or errors concerning data integrity.

Authentication Systems—Record actions performed within application authentication systems, including account creation, account terminations and account changes.

Record Access to Event Logs and Audit Trails—Record all access to application event logs and audit trails.

Record the Initialization or Termination of Event Logging Services—Record the initialization or termination of application event logging services.

Creation and Deletion of System Objects—Record the creation or deletion of system-level objects, such as applications, drivers or components.

Protect Event Logs from Unauthorized Modification—Application security functionality should detect event log tampering in the event that event log are not adequately protected from unauthorized modification.

Log Storage Capacity—Application log files must have sufficient capacity to meet reasonable log retention requirements. Archived application event logs should be retained for 12 months, with 3 months available online.

Synchronize System Time Clocks – Synchronize all critical system clocks and times to a centralized time server to ensure that all audit log timestamps throughout the organization are chronologically aligned.

Although not enumerated in HIPAA’s details, event information recorded in application event logs should include:

User Identification—Capture the username or user account associated with each logged action.

Type of Event—Capture the name or type of event for each logged action.

Date and Time—Capture the date and time associated with each logged action.

Action Success/ Failure—Capture the success/failure status for each logged action.

Event Origination—Capture the origination for each logged action.

Event Target/ Identity—Capture the name or identity of the affected data, system component or resource for each logged action.

9.0 Transmission Security

HIPAA Requirement

§164.312 Technical Safeguards—

§164.312(e)(1) Standard: Transmission security. Implement technical security measures to guard against unauthorized access to electronic protected health information that is being transmitted over an electronic communications network.

§164.312(e)(2)(i) Implementation specifications: Integrity controls (Addressable). Implement security measures to ensure that electronically transmitted electronic protected health information is not improperly modified without detection until disposed of.

§164.312(e)(2)(ii) Implementation specifications: Encryption (Addressable). Implement a mechanism to encrypt electronic protected health information whenever deemed appropriate.

Encrypt ePHI in Transit and Protect its Integrity

HIPAA’s “Encryption” implementation specification under the “Transmission Security” standard requires the implementation of a mechanism to encrypt ePHI whenever deemed appropriate, unless the organization concludes that it is not a reasonable and appropriate safeguard in its environment, when analyzed with reference to the likely contribution to protecting the entity's ePHI.

Implement strong, industry-acceptable cryptographic algorithms and associated key management procedures to encrypt electronic data while in transit across untrusted networks.

HIPAA’s “Integrity Controls” implementation specification under the “Transmission Security” standard requires the implementation of security measures to ensure that electronically transmitted ePHI is not improperly modified without detection until disposed of, unless the organization concludes that it is not a reasonable and appropriate safeguard in its environment, when analyzed with reference to the likely contribution to protecting the entity's ePHI.

Leverage cryptographic controls to ensure the integrity of data transmissions over untrusted networks. These controls should validate the authenticity of the message destination and origination, while assuring integrity and confidentiality of message content. If cryptographic controls cannot be leveraged, employ other electronic mechanisms to detect any unauthorized modification to ePHI transmitted across untrusted networks. Such mechanisms may include the use of digitally signed payloads or the use of balancing and reconciling techniques using file/field hash or control totals to detect integrity issues.

Summary

Building software is hard work. Software developers must manage thousands of details as they envision, design, build and test their software. Additionally, they have the added burden of building software that must be at least minimally compliant with increasingly demanding regulations such as those embodied in the HIPAA Security Rule.

In my experience, some software developers in the healthcare space are producing software meant to maintain ePHI, yet it is does not meet some of HIPAA’s requirements out of the box; and often, the requirements not met are among those that HIPAA requires unequivocally. Not surprisingly, the vast majority of software developers outside the healthcare space miss many more of the HIPAA security requirements.

This post is meant to highlight these concerns, the negative effects they can have on organization’s attempting HIPAA compliance, and in a small way influence software developers to evolve their applications toward both compliance and security best practices.

Please contact us if you have questions about SOC audits, HIPAA audits or related advisory services or wish to obtain a quote.