Introducing Heroku Private Spaces
blog.heroku.com
blog.heroku.com
How close does it come to making PCI-DSS Level 1 attainable on Heroku? What about HIPAA?
- is it now possible to write a script that generates network diagrams, etc., that are sufficient for PCI-DSS Level 1?
- is the rest of Heroku's datacenter process documented so that it can be given to a QSA?
- Would it now be possible for companies like Aptible to sell their core competency/service as a Heroku add-on?
- Can add-ons be launched inside a private space?
- Can access to Heroku, git deploys, etc., add-ons be 100% protected by multi factor authentication?
Addon provider here: haven't heard anything official from Heroku on this, so this is my own personal speculation based on the current public Provider API. It seems that Heroku Postgres and Redis are available, and while they're _technically_ addons, they naturally have access to somewhat privileged APIs and architectural information that other addons do not have.
Currently, when an addon is provisioned, we're given a region identifier for the US East and EU public regions. My uninformed guess is that Private Spaces amounts to "your dynos run on servers in a private VPC." IF the Postgres and Redis integrations were "quick 'n dirty," they could very well get provisioned within the same VPC. However, it also seems plausible that AWS VPC peering can be used for other addons to provide their own Private Spaces support.
So it seems to me the question comes down to whether Heroku can (and/or _wants_ to) support VPC pairing with addons via their Provider API, so that other providers can provide their own private spaces.
This would be a huge boon for add-on providers.
The biggest thing to consider when adding another layer onto your compliant stack is how easily you can prove compliance when your customers ask. Whether it's BAAs, SSAE 16 documentation or access to HIPAA or HITRUST audits, you need your partners to be able to provide you with not only the documentation but the expertise to discern what that documentation needs. When your partner decides to build something as an add-on to a stack like `Your product > Heroku > AWS`, you need to guarantee that the middle man can either answer all of your questions or can find the person downstream who can when it's relevant. As we've needed to work with partners and considered doing add ons with compliance, this has been the #1 question we've needed to answer first. In a world where your customers should be willing to pay for compliance, the person you call on the phone with questions about what it takes to achieve compliance on their stack should be able to tell you from experience what it's like going through a HIPAA, HITRUST or PCI audit.
Most of the documentation we've provided where I work on the subject is free online: http://catalyzeio.github.io/policies. You can see through the forks that folks have used the documentation to prove compliance not only on our platform at Catalyze but also on other stacks like AWS.
They asked us what we needed, and I responded with, "We need to be HIPAA compliant - what do we need to do to make that happen on Heroku?"
The sales rep immediately replied along the lines, "We don't do that."
He ended the call shortly after that, clearly uninterested in our money.
Since then, we started using Aptible (https://www.aptible.com)and they are AWESOME. The biggest difference for us is that they also provide the legal documentation and advice to working through HIPAA compliance. They're totally willing to go beyond just being a PaaS and really start to blend into a moderate level of legal counsel. Only downside is that their premium service entails a premium price.
Also have had impressively short conversations with SaaS product companies after the acronym HIPAA or BAA is brought up.
Most of HIPPA compliance (from an IT perspective) is having a comprehensive security policy and documenting that you're doing certain activities with the appropriate frequency: risk analysis, security audits, auditing user accounts and privileges, security training for users, etc.
I think the biggest barrier to getting HIPPA compliance on more infrastructure providers is that infrastructure providers are engineering organizations, and HIPAA is mostly a CYA activity for lawyers (plus some easy, obvious OPSEC).
I couldn't agree more
Recommended write-up: What is Heroku: getting started with PaaS development
Healthcare is the main concern here with HIPAA but it should also apply to insurance, finance, and some industrial use cases.
Furthermore, compliance is more than just doing the right thing. It's proving that you are compliant. There is immeasurable value with selecting a vendor who is audited to be HIPAA Compliant or HITRUST Certified because then the risk is offloaded to someone with credibility in the marketplace via a Business Associate Agreement. If you wanted to build your own HIPAA compliant stack on AWS, and you want to be taken as credible when trying to sell to a CIO at a hospital, then you will need to go through the procedure of becoming HITRUST Certified as well.
Otherwise you will just be nibbling at the edges and taking on all the risk while hampering your business model.
I'm pretty sure AWS has a package for HIPAA compliance that will checkmark most of the required fields outside of the application, and general settings fields. Most of the problems will come from the Application architecture. You can have a prebuilt envorionment for everything but if you're code is garbage then good luck.
Not sure how hosting in AWS is any different from hosting on Heroku, considering you're ultimately still responsible for the Application side. Does Heroku manages your logs in someway that AWS cannot?
Even with an agreement with a merchant, aren't you still responsible for your application code? Isn't that still subject to HIPAA requirements?
Also AWS is HIPAA compliant and they will do a Business Associate Agreement, and has been HITRUST certified iirc.
For the ease of math, let's say at the infrastructure level it takes "10" things be HIPAA compliant. An IaaS vendor like AWS will do about 1/10th of it, and do it very well. Mostly the firewall and physical safeguards. They do sign a BAA and claim to be HIPAA Compliant, but you need to keep in mind that it's only for a fraction of what you're ultimately responsible for. The other 9/10ths is nontrivial. It includes things like encryption, monitoring, vulnerability scanning, breach policies, how you handle your logs. Lots of things.
The difference between hosting on AWS vs. hosting on Heroku will be how many of those 9/10ths Heroku will automate for you, and then—here's the kicker—that they agree to in their Business Association Agreement with you. Even if they do the other 9/10ths, if they won't sign a BAA with you, then you're still at risk.
In essence AWS is an IaaS vendor who will sign a BAA that does a few compliant things, but you still have a long long journey ahead of you. You could build your own, certainly, on either AWS or Heroku. You could also look for a HIPAA Compliant Platform as a Service (PaaS) who automates the other 9/10ths and then signs a BAA for those things. The company I work for, Catalyze, is just that. We basically are the other 9/10ths on top of AWS, sign a BAA for it, and stand behind you with a HITRUST Certification.
The guide we wrote up on HIPAA Compliance might be of use to you: https://catalyze.io/hipaa-compliance. Also, our Academy entries might be helpful to understand the complexities: https://catalyze.io/learn.
For some super nerdy technical explanations, take a look at how Catalyze approaches the other "9/10ths" here: https://hipaa.catalyze.io
Not quite, in fact, the first thing you need to do to meet a BAA with many cloud vendors is terminate SSL locally. This means no using things like ELBs. What about if you need a VPN? How do you guarantee that traffic is still encrypted (let's say TCP) once it hits the VPC VPN to your application server. These are very real healthcare compliance scenarios which you would need to figure out a solution for on the infrastructure side which you would need to build buy. I'm sure there are similar things that need to be handled WRT PCI.
Application security is important (of course). I used to work on application security with hospital organizations at an EHR vendor, so even though we sell infrastructure I can help customers out when it comes to this topic. The reason why there isn't really an "Application Security checkbox" is because the question? "What is the correct amount of access to patient data" is a hard one. Prestigious healthcare organizations all the way down to startups struggle with it, so it's usually a more involved process.
Being able to demonstrate HIPAA compliance is different. You need to be able to:
1) Prove that a wide range of controls are in place and operating effectively, many of which are administrative (risk assessments, policy controls, workforce training, manual config reviews, access control reviews, etc.)
2) Keep all of your documentation current, even as your code and architecture changes.
If you DIY on AWS, you accept all of the risk for everything from the hypervisor up. Not just the risk of adversarial breach, but misconfiguration, inappropriate configuration, patching, etc.
There's a huge range of possible environments and combinations of add-ons available with Heroku and a huge range of available DevOps resources across companies. A small startup with no DevOps resources but a complicated Heroku app with fifteen add-ons will find their current setup vastly more cost effective than hiring someone to reproduce that setup on AWS.
People too often fail to account for human costs and just look at pricing tables to decide what's cost effective.