4 ms·

You could argue whether the attack on Zoom is warranted. But don't start revising history to make your point. E2E has never meant that. There's no such "old not

by DCKing 7y ago

You could argue whether the attack on Zoom is warranted. But don't start revising history to make your point. E2E has never meant that. There's no such "old notion". I can't find any sources saying HIPAA would use that deviating definition. Most sources I see use Whatsapp as an example, which is E2E under the proper definition.

SkyPuncher 7y ago
> I can't find any sources saying HIPAA would use that deviating definition. That's because HIPAA does not define any implementation details. Google "Hipaa end to end encryption" and you'll quickly realize the Hipaa world uses a much looser definition than the security world. "End-to-end" in the context of Hipaa is typically used to indicate encryption (specifically SSL/TLS) of on-the-wire data through the entire request process. Practically this means on-the-wire data needs to be protected all the way to the underlying app service. For example, if you're running Rails with Docker. SSL/TLS transport needs to be present all the way to the container. A load balancer (or other device) is allowed to terminate/re-encrypt as long as on-the-wire data remains protected.
- KaoruAoiShiho 7y ago
  While I think people need to chill out on Zoom I can't find any alternative standards for end to end with HIPPA. Zoom fucked up here.
- computerex 7y ago
  Instead of asking people to Google it, your argument would hold more weight if you provided the specific sources you mean readers to go Google and find themselves. It'll save readers some time and improve your argument. Several people have tried to "google it" and tried to find alternative definitions of end-to-end encryption in the context of HIPAA and have so far failed. If end to end encryption really does mean something else in the context of HIPAA, what is your evidence/source?
  - SkyPuncher 7y ago
    I'm suggesting people should Google it because a list of singular examples does not indicate widespread usage. It's a case of "you need to see for yourself" to understand how this term is actually used in the wild. The problem is people are trying to find definitions for things that Hipaa literally doesn't define. You won't find a definition for "end-to-end" because Hipaa doesn't actually define it. "end-to-end" is an implementation detail. Hipaa does not define or green-light implementations. This is both a blessing and a curse of Hipaa. On the blessing side, it means companies can use tools they see fit and follow industry best practices as long as they can demonstrate the compliance of those tools. This is great because it means companies don't need to wait for Hipaa to explicitly say "you can now use TLS 1.x" or "this widely accepted algorithm is cool for disk encryption". On the curse side, it means there's no explicit guidance and a lot of leeway. It's on individual companies to demonstrate their implementation patterns are secure.
- prophesi 7y ago
  From the actual HIPAA regulations, one must "Implement technical security measures to guard against unauthorized access to electronic protected health information that is being transmitted over an electronic communications network." Then you can follow along the official HHS guide[0] to see if you're abiding by these rules. If the intended recipient of your protected health information is another client, then SSL/TLS would not be HIPAA compliant. If the intended recipient is the server, then SSL/TLS is totally fine. As a sibling comment mentions, your company shouldn't be using random articles found through a search engine for HIPAA advice. [0] https://www.hhs.gov/sites/default/files/ocr/privacy/hipaa/administrative/securityrule/techsafeguards.pdf?language=es https://www.hhs.gov/sites/default/files/ocr/privacy/hipaa/ad...
  - SkyPuncher 7y ago
    > As a sibling comment mentions, your company shouldn't be using random articles found through a search engine for HIPAA advice. Trust me. I am not. I'm simply trying to demonstrate colloquial usage of the term within the Hipaa community. > If the intended recipient of your protected health information is another client, then SSL/TLS would not be HIPAA compliant. If the intended recipient is the server, then SSL/TLS is totally fine. This is not correct, though. Both of those use cases CAN be fine. They can both also NOT be fine. * Client-to-client (assuming we're talking about a computer client) over SSL/TLS is completely fine if the usage case allows for it. You don't need a server involved to exchange ePHI. * Conversely, client-to-server does not automatically make the use case allowable.
    - prophesi 7y ago
      Maybe it's because I use Qwant, but my search results for HIPAA end to end encryption gave articles about actual E2E encryption for emails (since they typically pass through a third-party email server). So I'm starting to think the term isn't being misused even in the HIPAA community. And sorry, I meant client-to-client with the assumption that there's a server between the two. And sure. I think it's safe to assume that SSL/TLS is perfectly fine for a client-to-server situation. But like I said, let the company read the actual regulations and consult their IT team.

by DCKing 7y ago

SkyPuncher 7y ago

> I can't find any sources saying HIPAA would use that deviating definition. That's because HIPAA does not define any implementation details. Google "Hipaa end to end encryption" and you'll quickly realize the Hipaa world uses a much looser definition than the security world. "End-to-end" in the context of Hipaa is typically used to indicate encryption (specifically SSL/TLS) of on-the-wire data through the entire request process. Practically this means on-the-wire data needs to be protected all the way to the underlying app service. For example, if you're running Rails with Docker. SSL/TLS transport needs to be present all the way to the container. A load balancer (or other device) is allowed to terminate/re-encrypt as long as on-the-wire data remains protected.

KaoruAoiShiho 7y ago
While I think people need to chill out on Zoom I can't find any alternative standards for end to end with HIPPA. Zoom fucked up here.
computerex 7y ago
Instead of asking people to Google it, your argument would hold more weight if you provided the specific sources you mean readers to go Google and find themselves. It'll save readers some time and improve your argument. Several people have tried to "google it" and tried to find alternative definitions of end-to-end encryption in the context of HIPAA and have so far failed. If end to end encryption really does mean something else in the context of HIPAA, what is your evidence/source?
- SkyPuncher 7y ago
  I'm suggesting people should Google it because a list of singular examples does not indicate widespread usage. It's a case of "you need to see for yourself" to understand how this term is actually used in the wild. The problem is people are trying to find definitions for things that Hipaa literally doesn't define. You won't find a definition for "end-to-end" because Hipaa doesn't actually define it. "end-to-end" is an implementation detail. Hipaa does not define or green-light implementations. This is both a blessing and a curse of Hipaa. On the blessing side, it means companies can use tools they see fit and follow industry best practices as long as they can demonstrate the compliance of those tools. This is great because it means companies don't need to wait for Hipaa to explicitly say "you can now use TLS 1.x" or "this widely accepted algorithm is cool for disk encryption". On the curse side, it means there's no explicit guidance and a lot of leeway. It's on individual companies to demonstrate their implementation patterns are secure.
prophesi 7y ago
From the actual HIPAA regulations, one must "Implement technical security measures to guard against unauthorized access to electronic protected health information that is being transmitted over an electronic communications network." Then you can follow along the official HHS guide[0] to see if you're abiding by these rules. If the intended recipient of your protected health information is another client, then SSL/TLS would not be HIPAA compliant. If the intended recipient is the server, then SSL/TLS is totally fine. As a sibling comment mentions, your company shouldn't be using random articles found through a search engine for HIPAA advice. [0] https://www.hhs.gov/sites/default/files/ocr/privacy/hipaa/administrative/securityrule/techsafeguards.pdf?language=es https://www.hhs.gov/sites/default/files/ocr/privacy/hipaa/ad...
- SkyPuncher 7y ago
  > As a sibling comment mentions, your company shouldn't be using random articles found through a search engine for HIPAA advice. Trust me. I am not. I'm simply trying to demonstrate colloquial usage of the term within the Hipaa community. > If the intended recipient of your protected health information is another client, then SSL/TLS would not be HIPAA compliant. If the intended recipient is the server, then SSL/TLS is totally fine. This is not correct, though. Both of those use cases CAN be fine. They can both also NOT be fine. * Client-to-client (assuming we're talking about a computer client) over SSL/TLS is completely fine if the usage case allows for it. You don't need a server involved to exchange ePHI. * Conversely, client-to-server does not automatically make the use case allowable.
  - prophesi 7y ago
    Maybe it's because I use Qwant, but my search results for HIPAA end to end encryption gave articles about actual E2E encryption for emails (since they typically pass through a third-party email server). So I'm starting to think the term isn't being misused even in the HIPAA community. And sorry, I meant client-to-client with the assumption that there's a server between the two. And sure. I think it's safe to assume that SSL/TLS is perfectly fine for a client-to-server situation. But like I said, let the company read the actual regulations and consult their IT team.