4 ms·

If anyone here is HIPAA-regulated or you have a customer who is, and you used Cloudflare during those dates, it is Big Red Button time. You've almost certainly

by patio11 10y ago

If anyone here is HIPAA-regulated or you have a customer who is, and you used Cloudflare during those dates, it is Big Red Button time. You've almost certainly got a reportable breach; depending on how tightly you're able to scope it maybe it won't be company-ending.

spydum 10y ago
Isn't it worse than that? Even if you are not a CF user, if your apps make calls to a third party site protected by CF, you could be at risk (stolen credentials, API keys), and could be attacked using those now.
- patio11 10y ago
  That's also a bad thing, but you can roll creds and check if anyone has exfiltrated data from your various accounts. You can't roll patient identities. There doesn't appear to be any way to figure out which of your HTTPS pages served in last 6 months are presently publicly exposed. I feel for folks who lost API keys -- really -- but everyone regulated should be in full-on disaster recovery mode right now.
chimeracoder 10y ago
> If anyone here is HIPAA-regulated or you have a customer who is Cloudflare certainly does; I founded a health tech company, and Cloudflare was the recommended go-to for health tech startups who needed a CDN while serving PHI. And this is definitely a reportable breach. Technically any breach is supposed to be reported to HHS, but in reality, a lot of covered entities (e.g. insurers) fail to report smaller breaches (which, as a patient, should terrify you). The big ones, though, are really, really bad, and when reported, the consequences can be very serious and potentially even include serving time, depending on the circumstances. The reason I can be so confident that this is a reportable breach is that the definition of PHI is so broad that even revealing the existence of information between two known entities can be considered protected information. Anything more specific, like a phone number or DOB, or time of an appointment (even if you don't know who the appointment corresponds to) - that's always protected. And Cloudflare certainly has many of those.
- tinco 10y ago
  Well HIPAA wouldnt allow your https traffic flow unencrypted through a shared proxy right? This means cloudflare couldnt offer that feature, so they probably didn't? Just think about the HIPAA document describing a single endpoint of dozens of sensitive datastreams, decrypting and then encrypting them all on the same machine, a machine that does some random HTML parsing for snippet caching on the side. I don't see that passing review, but perhaps I'm naieve..
  - mcintyre1994 10y ago
    From their blog post: https://blog.cloudflare.com/incident-report-on-memory-leak-caused-by-cloudflare-parser-bug/ https://blog.cloudflare.com/incident-report-on-memory-leak-c... "Because Cloudflare operates a large, shared infrastructure an HTTP request to a Cloudflare web site that was vulnerable to this problem could reveal information about an unrelated other Cloudflare site." You don't need to be using this feature, or to be sending malformed HTML yourself - just to be in memory for this Cloudflare process.
    - tinco 10y ago
      Apparently I was incorrect, and HIPAA does not require protected data streams to be isolated from each other. Perhaps I was confusing some other (European) regulation. For HIPAA it seems to be sufficient to promise that everything is secure, that you have documented everything and that you know what to do when stuff goes wrong. So we should see very quickly that Cloudflare knows what to do when stuff goes wrong.
    - dajohnson89 10y ago
      Why isn't the cloudflare encrypted with HTTPS??
      - wlesieutre 10y ago
        It probably was, but any encrypted data still exists in unencrypted form in the server's memory before it's encrypted and sent out over https. You have to have something to encrypt before you can encrypt it. The memory leaked by this bug includes that pre-encryption data, which is what we're seeing here. (At least that's my interpretation, computer security isn't quite my wheelhouse)
chasb 10y ago
If you are/were using Cloudflare to cache PHI though their CDN without a BAA, you were likely in breach before this. Some have suggested that Cloudflare might not be a business associate because of an exception to the definition of business associate known as the "conduit" exception. Cloudflare is almost certainly not a conduit. HHS's recent guidance on cloud computing takes a very narrow view[0]: "The conduit exception applies where the only services provided to a covered entity or business associate customer are for transmission of ePHI that do not involve any storage of the information other than on a temporary basis incident to the transmission service." OCR hasn't clarified what "temporary" means or whether a CDN would qualify, but again, almost certainly not. ISPs qualify, but your data just sits on the CDN indefinitely. p.s. Hi Patrick and Aditya! [0] https://www.hhs.gov/hipaa/for-professionals/special-topics/cloud-computing/index.html https://www.hhs.gov/hipaa/for-professionals/special-topics/c...
- cjcampbell 10y ago
  Agree completely with you on this, and based on my experience with OCR, I'd say they would as well. The analogy for a "mere conduit" is the postal service. And that analogy falls apart as soon as you realize that CloudFlare, when being used as an SSL termination point, is opening and repackaging each "letter" on the way to the destination. I do hate for CloudFlare to be the example for companies playing fast and loose with the rules, but I am hoping we'll have an opportunity in this to clarify the conduit definition a bit more. Would like to mention that I don't think this declaration applies to every scenario. CloudFlare isn't just one service. I don't see an immediate issue using CloudFlare for DNS on a healthcare app. Neither do I see an issue using CloudFlare as the CDN for static assets. Both of these cases should be evaluated in a risk analysis, but they don't necessitate the level of shared responsibility a BAA entails.

by patio11 10y ago

spydum 10y ago

Isn't it worse than that? Even if you are not a CF user, if your apps make calls to a third party site protected by CF, you could be at risk (stolen credentials, API keys), and could be attacked using those now.

patio11 10y ago
That's also a bad thing, but you can roll creds and check if anyone has exfiltrated data from your various accounts. You can't roll patient identities. There doesn't appear to be any way to figure out which of your HTTPS pages served in last 6 months are presently publicly exposed. I feel for folks who lost API keys -- really -- but everyone regulated should be in full-on disaster recovery mode right now.

chimeracoder 10y ago

> If anyone here is HIPAA-regulated or you have a customer who is Cloudflare certainly does; I founded a health tech company, and Cloudflare was the recommended go-to for health tech startups who needed a CDN while serving PHI. And this is definitely a reportable breach. Technically any breach is supposed to be reported to HHS, but in reality, a lot of covered entities (e.g. insurers) fail to report smaller breaches (which, as a patient, should terrify you). The big ones, though, are really, really bad, and when reported, the consequences can be very serious and potentially even include serving time, depending on the circumstances. The reason I can be so confident that this is a reportable breach is that the definition of PHI is so broad that even revealing the existence of information between two known entities can be considered protected information. Anything more specific, like a phone number or DOB, or time of an appointment (even if you don't know who the appointment corresponds to) - that's always protected. And Cloudflare certainly has many of those.

tinco 10y ago
Well HIPAA wouldnt allow your https traffic flow unencrypted through a shared proxy right? This means cloudflare couldnt offer that feature, so they probably didn't? Just think about the HIPAA document describing a single endpoint of dozens of sensitive datastreams, decrypting and then encrypting them all on the same machine, a machine that does some random HTML parsing for snippet caching on the side. I don't see that passing review, but perhaps I'm naieve..
- mcintyre1994 10y ago
  From their blog post: https://blog.cloudflare.com/incident-report-on-memory-leak-caused-by-cloudflare-parser-bug/ https://blog.cloudflare.com/incident-report-on-memory-leak-c... "Because Cloudflare operates a large, shared infrastructure an HTTP request to a Cloudflare web site that was vulnerable to this problem could reveal information about an unrelated other Cloudflare site." You don't need to be using this feature, or to be sending malformed HTML yourself - just to be in memory for this Cloudflare process.
  - tinco 10y ago
    Apparently I was incorrect, and HIPAA does not require protected data streams to be isolated from each other. Perhaps I was confusing some other (European) regulation. For HIPAA it seems to be sufficient to promise that everything is secure, that you have documented everything and that you know what to do when stuff goes wrong. So we should see very quickly that Cloudflare knows what to do when stuff goes wrong.
  - dajohnson89 10y ago
    Why isn't the cloudflare encrypted with HTTPS??
    - wlesieutre 10y ago
      It probably was, but any encrypted data still exists in unencrypted form in the server's memory before it's encrypted and sent out over https. You have to have something to encrypt before you can encrypt it. The memory leaked by this bug includes that pre-encryption data, which is what we're seeing here. (At least that's my interpretation, computer security isn't quite my wheelhouse)

chasb 10y ago

If you are/were using Cloudflare to cache PHI though their CDN without a BAA, you were likely in breach before this. Some have suggested that Cloudflare might not be a business associate because of an exception to the definition of business associate known as the "conduit" exception. Cloudflare is almost certainly not a conduit. HHS's recent guidance on cloud computing takes a very narrow view[0]: "The conduit exception applies where the only services provided to a covered entity or business associate customer are for transmission of ePHI that do not involve any storage of the information other than on a temporary basis incident to the transmission service." OCR hasn't clarified what "temporary" means or whether a CDN would qualify, but again, almost certainly not. ISPs qualify, but your data just sits on the CDN indefinitely. p.s. Hi Patrick and Aditya! [0] https://www.hhs.gov/hipaa/for-professionals/special-topics/cloud-computing/index.html https://www.hhs.gov/hipaa/for-professionals/special-topics/c...

cjcampbell 10y ago
Agree completely with you on this, and based on my experience with OCR, I'd say they would as well. The analogy for a "mere conduit" is the postal service. And that analogy falls apart as soon as you realize that CloudFlare, when being used as an SSL termination point, is opening and repackaging each "letter" on the way to the destination. I do hate for CloudFlare to be the example for companies playing fast and loose with the rules, but I am hoping we'll have an opportunity in this to clarify the conduit definition a bit more. Would like to mention that I don't think this declaration applies to every scenario. CloudFlare isn't just one service. I don't see an immediate issue using CloudFlare for DNS on a healthcare app. Neither do I see an issue using CloudFlare as the CDN for static assets. Both of these cases should be evaluated in a risk analysis, but they don't necessitate the level of shared responsibility a BAA entails.