Protecting ePHI Data on Mobile Applications for HIPAA – Part 1 (for Non-Geeks)
In a few days we will be publicly releasing our IronBox Secure File Transfer mobile application for Apple iOS devices on the App Store for our customers.
As with any software we produce here at IronBox, we focused specifically on mitigating risk from hacker attack and data breach. And since we knew that health care organizations under HIPAA would be using this app, we baked in specific security controls to help satisfy HIPAA requirements and addressable items. A lot went into this app (not just HIPAA related measures) and I thought sharing some of the key things we did might also help others in the profession, especially non-technical or non-developer type folks.
So in this article (part 1), I’ll personally walk you through the HIPAA Security Rule, specifically the Technical Safeguard sections and guide you through what we did to mitigate risk for our mobile application. And you don’t need to be a security geek to follow along.
The HIPAA Security Rule (Technical Safeguards)
The HIPAA Security Rule has three parts to help ensure the confidentiality, integrity and availability of electronic protected health information (ePHI). They are:
- Technical Safeguards
- Physical Safeguards
- Administrative Safeguards
In this article we’ll look specifically at the Technical Safeguards portion of the Security Rule. In later parts of this article I’ll also share with you the general security controls we implemented to keep data safe as we felt that implementing just the HIPAA Safeguards alone wasn’t sufficient for today’s threat landscape. Also I want to point out that the controls discussed here are just some of the key ones we implemented, so please don’t take this as your comprehensive or complete legal list.
If you go to http://www.hhs.gov/ocr/privacy/hipaa/understanding/srsummary.html and expand the Technical Safeguards button you’ll see the follow requirements (copied):
- Access Control. A covered entity must implement technical policies and procedures that allow only authorized persons to access electronic protected health information (e-PHI).
- Audit Controls. A covered entity must implement hardware, software, and/or procedural mechanisms to record and examine access and other activity in information systems that contain or use e-PHI.
- Integrity Controls. A covered entity must implement policies and procedures to ensure that e-PHI is not improperly altered or destroyed. Electronic measures must be put in place to confirm that e-PHI has not been improperly altered or destroyed.
- Transmission Security. A covered entity must implement technical security measures that guard against unauthorized access to e-PHI that is being transmitted over an electronic network.
Great, not a lot of detail, but if you open http://www.hhs.gov/ocr/privacy/hipaa/administrative/securityrule/techsafeguards.pdf (Update: the PDF referenced is no longer available) the HHS has an incredibly useful summary of the actual implementation specifications for the standards above. They are:
- Unique User Identification (Required)
-
Emergency Access Procedure (Required)
- Automatic Logoff (Addressable)
- Encryption and Decryption (Addressable)
- Audit Controls (Required)
- Integrity (Addressable)
- Person or Entity Authentication (Required)
- Transmission Security for Integrity (Addressable)
- Transmission Security for Encryption (Addressable)
Progress! Alright, let’s go through each of the specifications and see some of the key ways we addressed each specification. One more note, you’ll notice that each of these are either required or addressable. Our chief architect (i.e. me) tends not to take any shortcuts when it comes to security and data protection, so we just made each specification required. You might not have that luxury, so again treat this article as key things we did — not a checklist of things you must do.
Specification #1: Unique User Identification
For this specification, a covered entity (CE) must:
Assign a unique name and/or number for identifying and tracking user identity
What this means is that you need a way to uniquely identify users accessing our system or ePHI. This way you are able to hold people accountable to their actions on the system (what security geeks call non-repudiation) and they can’t easily refute those actions. The easiest way to do this is to assign each user something unique like a username. In our case we just used email addresses since it would be something our customers would already be familiar with and unique.
Specification #2: Emergency Access Procedures
For this specification, a covered entity (CE) must:
Establish (and implement as needed) procedures for obtaining necessary electronic protected health information during an emergency.
Preventing unauthorized people from accessing ePHI is important, but so is allowing authorized folks access to ePHI. With this specification, we implemented a method on our secure file transfer system whereby users can “delegate access” to ePHI to other users and control that level of access (Read, Write, Read/Write and Modify). We took it a step further and implemented a software policy feature where certain users (like admins) would automatically be delegated access to data which could not be revoked. This helped ensure that if say a user was on vacation, or passed away the ePHI under their supervision would always be accessible.
Specification #3: Automatic Logoff
For this specification, a covered entity (CE) must:
Implement electronic procedures that terminate an electronic session after a predetermined time of inactivity
The specific risk that this specification is trying to address is the risk of people leaving their device unattended or if it’s stolen. Someone could pick up that device, access that app and then get access to ePHI. Hello data breach. To address this (this is coming up in the next update to our app since it takes about 5+ days for Apple to review and release each app on their AppStore) we set a timer on the app. After a certain period of inactivity (20 minutes by default) is detected the app will automatically log the user out and force them to sign back in. We even did one step better and allowed admins to configure that time out via an admin dashboard so that the timeout matches their organization’s own time-out policy.
Specification #4: Encryption and Decryption
For this specification, a covered entity (CE) should:
Implement a mechanism to encrypt and decrypt electronic protected health information
This one I am not sure why the HHS feels this one is addressable since encryption is an integral method of protecting data, but as I mentioned earlier I made this required for our team. Even more interesting is that the HHS document doesn’t prescribe or even recommend certain algorithms or key sizes to use. In our case, we just defaulted to industry standard best practices and used Advanced Encryption Standard (AES) with a 256-bit key operating in CBC mode (this matters). We also turned on a handy iOS device feature called on disk encryption, which automatically encrypts your app’s disk space. It adds a little overhead in performance, but we think it’s worth it.
Specification #5: Audit Controls
For this specification, a covered entity (CE) must:
Implement hardware, software, and/or procedural mechanisms that record and examine activity in information systems that contain or use electronic protected health information
With this specification, a CE must provide some reporting method useful for examining information system activity. Our mobile app was designed to be more of a highly secure “conduit” by which you can access your data through our cloud interface. And not like a file-synchronization tool like Dropbox, Box or Microsoft Skydrive. Data (including logs) is not kept on the device long term, because there’s always a risk of the user losing that device and the data on it. This model has certain drawbacks. For instance, you can’t view ePHI on a plane while not connected to the Internet. It’s less convenient for the user, but much more secure. So we keep logs of activity of all access (mobile, Web, etc.) centralized and accessible through our Web interface.
Specification #6: Integrity
For this specification, a covered entity (CE) must:
Implement policies and procedures to protect electronic protected health information from improper alteration or destruction
ePHI needs to be protected from unauthorized access, but it also needs to be protected from unauthorized modification or destruction. To help prevent improper alteration or destruction of ePHI, one thing our app does it is re-authenticates the user on every access or command. Not just when they log in. We also use cryptographic hash value comparison (like comparing digital fingerprints) to detect unauthorized alterations. These controls are a little hard to show with a screenshot, so you’ll have to use your imagination for this one.
Specification #7: Person or Entity Authentication
For this specification, a covered entity (CE) must:
Implement procedures to verify that a person or entity seeking access to electronic protected health information is the one claimed.
This specification helps ensure that the person accessing ePHI is in fact who they claim to be. For this, we used password pairings with emails. You might wonder why we just didn’t rely on the device’s PIN number or access code. The reason is because a 4-digit code (in our opinion) isn’t sufficient if you’re serious about security. We had to assume that users might not have a password set or even a weak one, so we force users to login with full passwords on our mobile app. This is probably the least favorite feature our app, but hey between low-security-high-convenience or high-security-lower-convenience we’re picking higher security. Most users won’t appreciate this feature until after they suffer their first data breach.
Specification #8: Transmission Security for Integrity
For this specification, a covered entity (CE) must:
Implement security measures to ensure that electronically transmitted electronic protected health information is not improperly modified without detection until disposed of.
While ePHI is being transmitted, we need to help ensure that it’s not improperly modified, and if it is then we can detect this modification. One of the key ways to do this is by forcing all communications to all of our end points over an SSL (or TLS) enabled encrypted tunnel. The great thing about SSL/TLS is that it automatically provides you with integrity checking. Again, I am not sure why HHS is leaving this as an addressable item, because of all the specifications this was the easiest to implement.
Specification #9: Transmission Security for Encryption
For this specification, a covered entity (CE) must:
Implement a mechanism to encrypt electronic protected health information whenever deemed appropriate.
While ePHI is being transmitted, we need to help ensure that it’s encrypted and not accessible by unauthorized parties. Very similar to #8, we accomplished this by forcing all communications to all of our end points over an SSL (or TLS) enabled encrypted tunnel. SSL/TLS automatically encrypts data you send through it so it was no extra work. You will also want to make sure you’re using an SSL/TLS certificate that supports 2048-bit or higher public keys as the old standard (1024-bit) doesn’t cut it anymore. We also only decrypt data once it’s reached the mobile application, so in essence it’s double encrypted: once by us and a second time by the SSL/TLS tunnel.
Final Words
I hope you gained some insight by seeing what we did with our mobile app and that you found it useful. As I mentioned before, many more security measures went into our mobile app than just following the HIPAA Security Rule Technical Safeguard specifications. For example, in the next series I’ll show you what we did to help mitigate risks from bring-you-own-device (BYOD) scenarios. And we’re still not done (developing a secure app takes continuous effort and attention).
In the next part of this article, I’ll walk you through some of the additional measures we took above what’s required from HIPAA to help you prevent your next mobile data breach. Until then, thanks for reading.
–Kevin