CloudFlare, Data Breaches, and the HIPAA Conduit Exemption

The Conduit Exception

We’ve written in the past how the Omnibus rule for HIPAA, introduced in 2013, has affected companies doing business in the healthcare industry. One important clarification made in the Omnibus rule is additional guidance around what does and does not fall under HIPAA and the conduit exception.

The conduit exception was introduced for reasons of practicality. In effect, the exception states that no legal agreements are required between covered entities and organizations that merely act as “conduits” for ePHI.

In the physical world this makes a lot of sense. Without this exception it would be impossible for your doctor to discuss health issues over the phone or send medical bills over postal mail.

Things become a little blurrier in the electronic world. What exactly is the difference between an organization/service acting as a conduit for information and an organization/service acting as a business associate?

According to the legal wording,

… data transmission organizations that do not require access to protected health information on a routine basis would not be treated as business associates. This is consistent with our prior interpretation of the definition of “business associate,” through which we have stated that entities that act as mere conduits for the transport of protected health information but do not access the information other than on a random or infrequent basis are not business associates.

This is further clarified with:

The conduit exception is a narrow one and is intended to exclude only those entities providing mere courier services, such as the U.S. Postal Service or United Parcel Service and their electronic equivalents, such as, internet service providers (ISPs) providing mere data transmission services. As we have stated in prior guidance, a conduit transports information but does not access it other than on a random or infrequent basis as necessary to perform the transportation service or as required by other law.

So the final rule clearly calls out ISPs as falling under the conduit exemption and that a “random or infrequent basis” is the dividing line. This is a logical extension of the physical examples given earlier.

Are CDNs Exempt?

Unfortunately, the final rule does not cover CDN services explicitly. Let’s consider some of the cases where using a CDN makes sense and map them to the guidelines above.

One typical use for CDNs is to place static content geographically closer to end users, for example, static HTML or Javascript libraries. These are obviously not ePHI but often fall under HIPAA for various reasons.

For instance, if you have a web application and are dynamically loading Javascript from a CDN, and if that CDN were ever compromised, any maliciously-injected code could feasibly be used to exfiltrate ePHI out of your application. If you’re not cryptographically verifying the content downloaded from the CDN you are opening up yourself to attack vectors. In this case, the CDN would definitely not be covered by the conduit exemption; after all, it is storing executable code on your behalf.

Another use involves using the CDN to proxy an application server, essentially acting as a global caching layer. Some CDNs claim that because they offer encryption support (HTTPS), and they are simply acting as a path for cached information, they are exempt under the conduit exception. Unfortunately this argument is invalid and falls apart under scrutiny.

Some CDNs require you to upload a copy of your HTTPS certificate and private key in order to get HTTPS support. In this case, if that certificate is also used to protect ePHI, this is definitely not covered by the conduit exception. You are providing keying material that can be used to decrypt sensitive information. Not only would this fall under HIPAA legislation, this is bad security hygiene.

Even if the CDN uses a separate HTTPS certificate and private key, if it is acting as a proxy in front of a health-related application the CDN’s servers will likely receive, decrypt, and transmit ePHI. In contrast with an ISP the CDN will have access to ePHI on much more than a “random or infrequent” basis.

Additionally, simple metadata related to some websites may be sensitive. How would you feel if leaked HTTP request logs showed a username that corresponds with your Twitter handle visiting an intensely personal website such as a disease-focused dating site? Depending on what information is tracked in the request URLs, even web server access logs may inadvertently contain ePHI.

One can picture data centers full of HTTPS frontends silently processing data that may contain sensitive information. Given that the CDN staff has administrative access to those machines, how can you be sure any ePHI that happens to traverse through their network is being properly protected? What legal actions do you have in case it is not being handled correctly?

The Importance of the BAA (Business Associate Agreement)

These issues were some of the key motivators for introducing the concept of the Business Associate Agreement, or BAA. In HIPAA, these legal agreements are used for a few important reasons:

1. To clearly define expectations around how both parties follow HIPAA regulations, particularly around how data containing ePHI will be managed.
2. To delineate the risks and responsibilities between both parties, particularly around breach notifications and penalties.

Without such a legal agreement in place allowing a third party to access data containing ePHI is a risky proposition. How will you know if data is being properly protected? If a security incident happens related to ePHI for your customers, how you will be notified so you can take appropriate actions?

If there is no agreement in place there is not a clear legal course of action to take in the event of a breach. In fact, given the way HIPAA regulations are enforced, without a BAA you will be liable for any mistakes made by that third party.

The fiscal repercussions of being on the hook for a breach caused by a third party is compelling enough for organizations to ensure that any services they use are covered under a BAA. But more importantly, the legal framework of the BAA means that you will have done at least a token amount of due diligence in protecting your customer’s ePHI data. Allowing sensitive data to flow through a third party without such diligence is irresponsible and shows a complete lack of respect for your customer’s basic privacy rights.

Or as Gene Fry summarized so succinctly:

Any provider that states they are fully HIPAA compliant will sign a BAA with you, and if they don’t, you’re putting your organization and patients’ data at risk.

Impact of the CloudFlare Breach

Given the scale at which CloudFlare operates, the impact of this breach will likely take a long time to fully flesh out. While CloudFlare reacted quickly to respond to this breach it will take some time to regain the trust they lost with this catastrophic mistake.

To the best of our knowledge CloudFlare has never offered a BAA for their customers, which means that any organization that used CloudFlare’s CDN capabilities with ePHI needs to start invoking their breach procedures now. We hope all such organizations do the right thing and help protect any sensitive data entrusted to them by their customers.

Learn more about how Datica Compliant Cloud lets you move fast on leading infrastructure providers, like AWS and Azure, while keeping the compliance folks happy.