nusbaum
By:
nusbaum

How can I achieve HIPAA compliance on a DigitalOcean hosted solution?

September 15, 2016 3.3k views
Security CentOS

Let me start by saying this isn't a trivial ask of a very complex question, I'm already deep into this and I'm looking to see if anybody else has encountered this challenge and perhaps found a solution.

To start off, we have a solution already running on digitalocean and a new client would like to add some data that would be considered Protected Health Information (PHI), which would make us a Business Associate to their organization as a HIPAA covered entity. The general approach here is that we need to get a Business Associate Agreement (BAA) signed by our hosting provider, but DigitalOcean will not sign BAA agreements (Amazon will, but don't want to go there). I didn't want to give up, so I did some more digging.

I've gone through the HIPAA security requirements and it seems that having a BAA signed by the hosting provider is typically required to cover physical protection of the PHI stored on the hosting provider's servers. My assertion is that if physical access to our servers cannot provide access to PHI, then we don't need a BAA signed by DigitalOcean. Has anybody else had to dig into this and come to the same conclusion?

The physical risks I have identified so far include:

  1. A system could be shut down and access to PHI limited.
  2. A system could be destroyed and PHI lost.
  3. A drive could be remove from a system and PHI copied from it.
  4. A drive could be removed from a system and security measures disabled.
  5. A system could be accessed by somebody at the hosting provider (back door) and data removed.
  6. A system could be accessed by somebody at the hosting provider (back door) and security measures disabled.

Any thoughts on risks that might be missing here?

I already have some thoughts on a number of these risks:

  1. Our solution has fail over to a different physical location, so covered.
  2. Data is replicated in real time to another physical location and backed up off-site.
  3. I'm not sure if a drive can be removed and data left intact on the DigitalOcean platform, but I think MariaDB 10.1 with encryption at rest may address this as long as I keep the encryption key off of the server.
  4. Remotely check for changed configuration files?
  5. Can I assume there is no backdoor into our servers without a signed agreement to that affect?
  6. Can I assume there is no backdoor into our servers without a signed agreement to that affect?

If I can build a solid list of risks and mitigation strategies, I'll pull it together in a DigitalOcean Tutorial and hopefully our shared knowledge and expertise can make DigitalOcean a viable platform for HIPAA compliant solutions.

Thanks in advance for any help you might be able to offer.

2 comments
  • I'd be happy to show one of our HIPAA compliance experts this and see if there are any possible walkarounds. If anyone has any direct questions please let me know and I'd be happy to help.

  • This is the heart of my challenge and perhaps a question you could ask for me.

    If an application is designed to handle encryption of PHI from the time it is entered until the time it is rendered back on the screen, without dependencies on infrastructure services, then do we need to pursue a BAA from the provider of our infrastructure services?

    In our case, PHI is encrypted in the application before it is ever written to storage (file or database). The user provides a second HIPAA access key when they sign in. We, the application provider cannot read the data and the hosting provider would definitely not be able to read the data, even if they pulled a drive from a machine.

    The only real exposure here would be if the hosting provider, DigitalOcean, had a "back door" into our virtual machines and could change application code. If DigitalOcean can achieve PCI compliance, than I would think this has been addressed.

8 Answers

A great question. You're correct that we currently do not sign BAA documents but our security team is looking at ways we can, in the future provide these types of services. While it is currently possible to run PCI compliant systems on the DigitalOcean cloud, to the best of our knowledge, it is not currently legally possible to store PHI in compliance with HIPPA regulations on DigitalOcean.

Unfortunately, there's a lot more to HIPAA compliance than just having solid IT and security controls. In order to sign a BAA, the company has to have policies and procedures for handling of PHI and has to train all of their staff on HIPAA regulations. There are also mandatory risk assessments and other procedures that have to be performed and documented.

There are other implications as well, such as insurance costs (breach insurance is on the rise) and the risk of stiff fines (up to $1.5M per incident) for non-compliance. For this reason, many hosting providers cannot or will not sign a BAA without significant fee increases. Even Amazon charges a penalty by forcing you to run dedicated instances, at an additional cost of $1500+ per month.

You might consider looking at one of the specialized healthcare cloud providers, such as Healthcare Blocks.

So the answer is to move to our solution to AWS? I'm not ready to accept that.

I've gone through every line item in the security rule, that would pertain to being a SaaS provider, and I haven't seen anything that I don't think could be addressed with some thought and quality IT work. Has the DigitalOcean security team researched and found a deal breaker? If so, can they share their status so we can work together on this.

I realize our 8 virtual servers are pretty small right now, but I cannot believe the answer is simply "go away".

Thanks Douglas, that amazon thing about dedicated instances just got me as I had missed that line in the Amazon doc. $1496 monthly for a dedicated fee.

I have gone through the HIPAA documentation and I have walked through a risk assessment from two different perspectives.

Yes, the covered entity has to train their staff on how to handle PHI. But, if the solution is designed so that Digital Ocean staff can never see PHI data and if our staff cannot see PHI, then why does DigitalOcean need to carry any risk?

I appreciate your your points and I'm not trying to be argumentative. I just didn't want to drop this so easy. This simple fact is that we keep the cost of our service low because every dollar we charge is a dollar that these small non-profits cannot apply to their constituents. Sad thing is that I will probably have to drop this because I am more afraid of lawyers and bureaucrats than I am of the hackers.

  • I know I'm a year behind but... "I am more afraid of lawyers and bureaucrats than I am of the hackers." I love that line. I'm right there with ya on that!

Has there been any update on this thread? nusbaum's postings match much of what I have painstakingly determined as well. I, too, am working on a system that is required to store ePHI and this issue is pretty much a show-stopper for the entire project.

The crux of my confusion about this issue is nusbaum's statement: "But, if the solution is designed so that Digital Ocean staff can never see PHI data and if our staff cannot see PHI, then why does DigitalOcean need to carry any risk?" I fundamentally don't understand why it's even necessary for my company to sign a BAA with Digital Ocean in order for my system to be HIPAA compliant? Because of nusbaum's statement.

@jsclev Fundamentally understanding "why it's even necessary" to "sign a BAA" is not necessary for anything (being rational is not part of the deal). It's baked-into and otherwise part of the HITECH-Act which you can read about for yourself at: https://www.hhs.gov/hipaa/for-professionals/special-topics/cloud-computing/ The guidelines (purely in my opinion) have gone completely off the deep end and compliance is a cost which we will pass on to our customers. I spent a large portion of my day reading the documentation and come to understand the explicit BAA requirement. Unless a cloud provider signs a BAA it doesn't matter what you do with the data, the service is not in compliance (with the very specific transit exclusion mentioned on hhs.gov, linked above).

  • Yes, I've usually found most of the rules are actually pretty reasonable only because it really is difficult to run a secure IT shop. I'm a bit surprised by the requirement of a BAA even if the data is encrypted and the keys are safe. But, I suspect they've studied the issue. The decades I've been managing software development has taught me one thing: programmers make mistakes. And, I suspect if they would allow the exception, it would be justified by plenty of programmers, and plenty will really implement the encryption improperly. There are a few other issues for Business Continuity Planning. Sure the Covered Entity should and can take charge of that issue, but the HIPAA security rule is concerned about continuity of service and disaster planning. So, the encryption issue is only part of the problem. By requiring a cloud vendor to sign a BAA and abide by HIPAA/HITECH, they have to do the full BCP. There is some value in that, too.

Thanks for jumping in @jimmont, I think that hipaa guidance has gotten even more specific since I last reviewed it. I wrote my original post after working through a hipaa security assessment and I was convinced I could meet the intent of the law by having my data encrypted at rest and the encryption keys vaulted.

  • Hello,

    TLDR: NOT OK. Looking at the reasoning, you would think you are fine. IF you are encrypting before it reaches Digital Ocean, it remains encrypted on their servers, and they don't have the keys, then it's impossible to have a breach on their servers. I want to use Digital Ocean, but I'm using AWS. I'm concerned that a single IT mistake can fail to properly encrypt the entire chain of control. But, if you've considered that as part of your Risk Analysis, and you are willing to take it, you would think it's OK. But, it's NOT according to the latest guidance!

    Details:

    I'm a HIPAA consultant and IT professional. The challenge in this space is that it's difficult to find someone that understands the law and the technology. The Privacy Rule is easier to understand for an attorney or someone who is more bureaucratic. But, the Security Rule and related Breach is challenging because there are so many subtleties and a proper implementation means understanding the law, interpretation, and the technology used to implement it. The law is also written in a manner to be flexible enough to apply to small and large organizations. I've been targeting the SMB market and it's scary how few are compliant. I believe the law is fine, and most of it is common sense. To many SMB it looks like it's completely overkill. Encrypt?! Regular backups, and I have to restore and test?! Train all users yearly?! Review my business associates and see if they are protecting the data?! Etc... Of course, any good IT shop will do these things as good practices, but to an SMB it seems like overkill. The good news is that technology is making it easier for an SMB to comply. Shameless plug: my company is using AI and machine learning to make it easier.

    Your encryption strategy looks sound and the examples the OCR is using and justification for requiring a cloud vendor to sign a BAA are addressed by your description look reasonable. Having said that, I wouldn't do it because I'm not willing to take the risk. But, it's far from reckless and I would respect the decision if I was doing a vendor audit. BUT, the OCR doesn't agree with my analysis. I guess they feel it's too risky. They've specifically addressed this issue: https://www.hhs.gov/hipaa/for-professionals/special-topics/cloud-computing/index.html

    This is the paragraph that addresses your issue:

    "When a covered entity engages the services of a CSP to create, receive, maintain, or transmit ePHI (such as to process and/or store ePHI), on its behalf, the CSP is a business associate under HIPAA. Further, when a business associate subcontracts with a CSP to create, receive, maintain, or transmit ePHI on its behalf, the CSP subcontractor itself is a business associate. This is true even if the CSP processes or stores only encrypted ePHI and lacks an encryption key for the data. Lacking an encryption key does not exempt a CSP from business associate status and obligations under the HIPAA Rules. As a result, the covered entity (or business associate) and the CSP must enter into a HIPAA-compliant business associate agreement (BAA), and the CSP is both contractually liable for meeting the terms of the BAA and directly liable for compliance with the applicable requirements of the HIPAA Rules."

Have another answer? Share your knowledge.