When HIPAA was introduced in 1996, the focus was solely on regulating and protecting patient health information (PHI) – it was conceived without any reference to any specific technologies used to connect to, access, and utilize the data. Subsequently, the Department of Health and Human Services (HHS) implemented the HIPAA Privacy Rule to establish safeguards to protect the use and disclosure of PHI data. And in 2013, HHS developed the HIPAA Security Rule – a set of generic standards to protect electronic PHI (ePHI). Violations of HIPAA are considered to be any violation of the Security, Privacy, or Breach Notification Rules by any type of covered entity listed within HIPAA.
But even back in 2013 – let alone 1996 – I don’t think the architects of HIPAA or its Rules had the forethought to conceive that those individuals utilizing ePHI would all be working from the comfort of their own home, on a personal device. It may initially sound like that’s no big deal but, as you’ll see in a moment, it’s relatively easy to demonstrate a HIPAA violation in scenarios where remote workers are involved:
- Insecure Internet Access – The transmission of ePHI over an insecure network is a violation. Now think about unencrypted Wi-Fi at employees’ homes, at the local coffee shop etc., and you quickly realize how easy it would be for threat actors to access the data. Remember, the insecure transmission itself is enough to be found in violation; it’s not necessary that a malicious actor gains access to the ePHI being transmitted.
- Unauthorized Devices – If a covered entity leverages a web-based application whereby remote users can access ePHI, there are likely no security controls in place to restrict or limit which user devices can connect to the application. HIPAA requires all devices using, gathering, storing, or transferring ePHI to be protected by specific security controls.
- Improper Disposal of Files Containing ePHI – A remote user working on a file containing ePHI may simply delete the file when done with it. But if it’s not securely deleted (where the blocks storing the file are overwritten many times to ensure an inability to salvage the file), it’s relatively easy for a malicious actor to undelete the file.
- Unencrypted Data at Rest – If data is to remain on a remote device, it’s required to be encrypted. Now think about, say, a Word doc that contains some patient details; we both know that a regular healthcare user isn’t going to take steps to ensure that file is encrypted when they’re done working on it.
- A Lack of Physical Security – Let’s face it; the physical security at your employee’s home doesn’t involve door badges, security guards, etc. And any kind of attempt to gain access to a remote device is going to be done logically (not physically) via some form of remote control, somewhat bridging the gap here between physical and network security.
One of the challenges organizations (healthcare or otherwise) have had to address in the last three years was how to ensure remote users could gain access to corporate resources. The cloud made things easy enough, driving users directly to cloud applications, platforms, and data. As did VPNs to connect those same remote users to internal corporate resources.
But little of those answers had anything to do with security; they were about productivity. Today’s organization that is subject to HIPAA needs to also consider whether any of the violations above are possible with their current configuration (here’s a hint: if ePHI data is transmitted to a personal device on a WiFi network the organization hasn’t sanctioned, you’re likely already in violation).
Enter Secure Remote Access.
Using Secure Remote Access to facilitate a remote worker’s access to ePHI does a few things to change whether ePHI is technically transmitted and where the ePHI logically exists.
- It logically keeps the data within the organization – Whether the remote worker is accessing ePHI using an application in the cloud or data on the corporate network, by requiring them to first securely access a remote desktop and use that desktop to access the ePHI, the data never leaves the organization and leverages the organization’s controls to maintain encryption at rest.
- No ePHI is transmitted to the remote device – The only data sent to the remote device serving as the client is screen data; the ePHI safely resides only on the remotely accessed desktop, further keeping ePHI off a user’s personal device.
- The connection is encrypted – Even when using a completely insecure Wi-Fi network, the remote access session itself is encrypted, ensuring that the ePHI access within the session is, therefore, also encrypted.
- The remote access must be authorized – By requiring multi-factor authentication, it’s possible to eliminate concerns around physical security (as only the actual owner of a credential can authenticate), as well as logically eliminate the issue of an unauthorized device (as the remote session is a sanctioned session on an internal desktop by an authenticated user.
In the end, by switching to using Secure Remote Access, organizations subject to HIPAA find themselves working in a far more secure environment where the expected violation “opportunities” that will (rather than may) occur disappear due to the logical shifting of the access to and use of ePHI to an approved desktop remotely accessed by the healthcare employee.
