4 ms·

Putting a third party analytics tool on a page containing PHI is an incredibly dangerous thing to do. It’s really surprising the developers could get that throu

by wrs 2y ago

Putting a third party analytics tool on a page containing PHI is an incredibly dangerous thing to do. It’s really surprising the developers could get that through a security review.

donohoe 2y ago
What security review?
stackskipton 2y ago
As someone who has worked in this field, I'm not. Marketing is generally exempt from massive legal review as they hand wave away "We don't deal with HIPPA data" and developers just wanting marketing to go away, dropped the Javascript block into files that were used for a ton of products including HIPAA containing ones. EDIT: Most of these places are just feature factories with offshore developers who are very unlikely to raise concerns.
- chimeracoder 2y ago
  > As someone who has worked in this field, I'm not. Marketing is generally exempt from massive legal review as they hand wave away "We don't deal with HIPPA data" and developers just wanting marketing to go away, dropped the Javascript block into files that were used for a ton of products including HIPAA containing ones. I don't know why you're being downvoted, because this is unfortunately quite accurate. You'd be shocked how often this happens, even for tools they think are totally secure and "HIPAA-compliant". > EDIT: Most of these places are just feature factories with offshore developers who are very unlikely to raise concerns. I don't think there's any meaningful difference based on where the developers are located. The developers aren't the ones making the decisions. Usually the issue is that the higher-ups want it, which is why practices can continue even after concerns are raised.
  - gausswho 2y ago
    I worked at an org that give Google Tag Manager access to marketing, effectively as means of bypassing engineering to try whatever spyslime of the month they could paste into a box.
unyttigfjelltol 2y ago
I would turn that around to be an inference that there was no effective security review....
AlotOfReading 2y ago
Kaiser was hit with a class action for exactly the same issue last year: https://news.bloomberglaw.com/litigation/patients-advance-kaiser-class-action-over-google-info-sharing https://news.bloomberglaw.com/litigation/patients-advance-ka... GoodRx, BetterHelp, and dozens of others have received notices that this is an issue. The federal OCR even published a bulletin about this 3 years ago. You'd think that any one of these would have triggered internal reviews and discovered this issue for all the others, but that's much too high a bar to expect in healthcare.
- knowitnone 2y ago
  Good. Hope Blue Shield gets the same treatment but they'll just pass the costs to their customers
ajross 2y ago
It's only surprising when you phrase it like that. Real bugs are interactions. I mean, sure, if you're asked to review a pull request like "patient_info: Use google to track MRI data", it's a no brainer. But no doubt the analytics blurb was stuffed into a generic "top_level_page" generator or whatever. And it happens that the PHI wasn't firewalled by design, and pulled it in by default. Or it was firewalled, but then someone forgot and migrated the "patient_info_page" templates to a generic framework, etc... Security is really, really hard. And one of the worst responses to a mistake like this is to tut-tut about how obvious a mistake and how easy to avoid it was. Believing that secure software is a matter of "not making mistakes" makes you more likely to write such bugs and not less, because you won't take the time to establish clear boundaries from the start.
- int_19h 2y ago
  Thing is, that's exactly what security and privacy reviews are for. If there was no review, that's negligence. If there was a review, one of the first questions that would be asked is, "what kind of tracking or telemetry do you have"? And there are tools that will scan code and flag things like that for you that large companies normally use.
- wrs 2y ago
  This is sort of like saying it's easy to crash an airplane so you shouldn't be surprised when somebody flies one into the ground. Everyone involved with aircraft knows crashes are bad and there are multiple layers of design and training to prevent it. Similarly, everyone at Blue Shield should know they can be fined outrageous amounts for a systemic HIPAA breach, so the system design and code review processes should make it really difficult to mess this up. Anything else is surprising. I have been in charge of such systems, and you can do a lot with pretty simple rules, such as: No external scripts can appear on a page containing PHI, with exceptions reluctantly approved by security review for things like performance monitoring (not advertising). Systems that can access PHI are a separate codebase from marketing. The marketing systems don't connect to anything with PHI in it. If anyone feels constrained by these rules, pull in the compliance team and discuss.
  - 2y ago

by wrs 2y ago

Putting a third party analytics tool on a page containing PHI is an incredibly dangerous thing to do. It’s really surprising the developers could get that through a security review.

donohoe 2y ago

What security review?

stackskipton 2y ago

As someone who has worked in this field, I'm not. Marketing is generally exempt from massive legal review as they hand wave away "We don't deal with HIPPA data" and developers just wanting marketing to go away, dropped the Javascript block into files that were used for a ton of products including HIPAA containing ones. EDIT: Most of these places are just feature factories with offshore developers who are very unlikely to raise concerns.

chimeracoder 2y ago
> As someone who has worked in this field, I'm not. Marketing is generally exempt from massive legal review as they hand wave away "We don't deal with HIPPA data" and developers just wanting marketing to go away, dropped the Javascript block into files that were used for a ton of products including HIPAA containing ones. I don't know why you're being downvoted, because this is unfortunately quite accurate. You'd be shocked how often this happens, even for tools they think are totally secure and "HIPAA-compliant". > EDIT: Most of these places are just feature factories with offshore developers who are very unlikely to raise concerns. I don't think there's any meaningful difference based on where the developers are located. The developers aren't the ones making the decisions. Usually the issue is that the higher-ups want it, which is why practices can continue even after concerns are raised.
- gausswho 2y ago
  I worked at an org that give Google Tag Manager access to marketing, effectively as means of bypassing engineering to try whatever spyslime of the month they could paste into a box.

unyttigfjelltol 2y ago

I would turn that around to be an inference that there was no effective security review....

AlotOfReading 2y ago

Kaiser was hit with a class action for exactly the same issue last year: https://news.bloomberglaw.com/litigation/patients-advance-kaiser-class-action-over-google-info-sharing https://news.bloomberglaw.com/litigation/patients-advance-ka... GoodRx, BetterHelp, and dozens of others have received notices that this is an issue. The federal OCR even published a bulletin about this 3 years ago. You'd think that any one of these would have triggered internal reviews and discovered this issue for all the others, but that's much too high a bar to expect in healthcare.

knowitnone 2y ago
Good. Hope Blue Shield gets the same treatment but they'll just pass the costs to their customers

ajross 2y ago

It's only surprising when you phrase it like that. Real bugs are interactions. I mean, sure, if you're asked to review a pull request like "patient_info: Use google to track MRI data", it's a no brainer. But no doubt the analytics blurb was stuffed into a generic "top_level_page" generator or whatever. And it happens that the PHI wasn't firewalled by design, and pulled it in by default. Or it was firewalled, but then someone forgot and migrated the "patient_info_page" templates to a generic framework, etc... Security is really, really hard. And one of the worst responses to a mistake like this is to tut-tut about how obvious a mistake and how easy to avoid it was. Believing that secure software is a matter of "not making mistakes" makes you more likely to write such bugs and not less, because you won't take the time to establish clear boundaries from the start.

int_19h 2y ago
Thing is, that's exactly what security and privacy reviews are for. If there was no review, that's negligence. If there was a review, one of the first questions that would be asked is, "what kind of tracking or telemetry do you have"? And there are tools that will scan code and flag things like that for you that large companies normally use.
wrs 2y ago
This is sort of like saying it's easy to crash an airplane so you shouldn't be surprised when somebody flies one into the ground. Everyone involved with aircraft knows crashes are bad and there are multiple layers of design and training to prevent it. Similarly, everyone at Blue Shield should know they can be fined outrageous amounts for a systemic HIPAA breach, so the system design and code review processes should make it really difficult to mess this up. Anything else is surprising. I have been in charge of such systems, and you can do a lot with pretty simple rules, such as: No external scripts can appear on a page containing PHI, with exceptions reluctantly approved by security review for things like performance monitoring (not advertising). Systems that can access PHI are a separate codebase from marketing. The marketing systems don't connect to anything with PHI in it. If anyone feels constrained by these rules, pull in the compliance team and discuss.
- 2y ago