3 ms·

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

by 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.
- tpmoney 2y ago
  The statement seems to imply that it was one of these "external scripts...reluctantly approved...for...performance monitoring". Specifically google analytics. But google is an all consuming vacuum for information, and presumably defaults to sharing data between your analytics account and your ads account. And in today's modern software dev world where everything is dependent on everything, that's exactly the sort of setting that could get accidentally imported somewhere where it wasn't supposed to. In fact it's also possible this came about because a page changed over time and no one re-reviewed that original approval. Imagine for example that they had some un-authenticated pages set up so that people could see what sort of Medicare plans BS offers. Every year, thousands of people flock to the site, drop their zip code in and see what plans are available in their area. So far so good, no PHI (zip + medicare without anything else isn't generally PHI). Then a year later someone gets the bright idea to let you search for which doctors are in or out of network. Again, not PHI for most practical purposes. Yes, it could be enough data to uniquely identify someone and their health conditions, but in practice, it's hardly going to raise any red flags. Next year someone suggests adding the ability to list your medications so that you can see what you out of pocket costs for a plan will be. We're edging up on PHI here, but as long as they're not taking actual personally identifying info like dates of birth or addresses, this probably still isn't getting flagged as a PHI page. Finally the next year someone suggests "wouldn't it be handy if our existing customers could have their medications and providers from the prior year just imported into the search automatically. Well sure it would, so they go ahead and implement it but whoops, pulling that data out of the system also pulled along some internal tracker id that happens to be composed partially of their external "HIPAA safe" analytics ID that gets mapped to the internal tracking ID so they can got analytics attached to your session even before you authenticate. And now that ID is matched up to health information in a way that both creates a unique connection between the health information and an individual and now also links that individual to a specific cross-site google tracking ID. And now you've had a data breach, without ever (intentionally) approving the application of marketing libraries on a PHI containing site. I agree that there should be a lot more safeguards still, but the bug also being in place between 3-4 years suggests to me that it was a lot more subtle than just "don't include `ads.google.js` on the patient's medical history page". It's possible they really are just completely inept and haven't had any audits in 5 years but we won't really know that unless/until someone leaks more details.

by ajross 2y ago

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.

tpmoney 2y ago
The statement seems to imply that it was one of these "external scripts...reluctantly approved...for...performance monitoring". Specifically google analytics. But google is an all consuming vacuum for information, and presumably defaults to sharing data between your analytics account and your ads account. And in today's modern software dev world where everything is dependent on everything, that's exactly the sort of setting that could get accidentally imported somewhere where it wasn't supposed to. In fact it's also possible this came about because a page changed over time and no one re-reviewed that original approval. Imagine for example that they had some un-authenticated pages set up so that people could see what sort of Medicare plans BS offers. Every year, thousands of people flock to the site, drop their zip code in and see what plans are available in their area. So far so good, no PHI (zip + medicare without anything else isn't generally PHI). Then a year later someone gets the bright idea to let you search for which doctors are in or out of network. Again, not PHI for most practical purposes. Yes, it could be enough data to uniquely identify someone and their health conditions, but in practice, it's hardly going to raise any red flags. Next year someone suggests adding the ability to list your medications so that you can see what you out of pocket costs for a plan will be. We're edging up on PHI here, but as long as they're not taking actual personally identifying info like dates of birth or addresses, this probably still isn't getting flagged as a PHI page. Finally the next year someone suggests "wouldn't it be handy if our existing customers could have their medications and providers from the prior year just imported into the search automatically. Well sure it would, so they go ahead and implement it but whoops, pulling that data out of the system also pulled along some internal tracker id that happens to be composed partially of their external "HIPAA safe" analytics ID that gets mapped to the internal tracking ID so they can got analytics attached to your session even before you authenticate. And now that ID is matched up to health information in a way that both creates a unique connection between the health information and an individual and now also links that individual to a specific cross-site google tracking ID. And now you've had a data breach, without ever (intentionally) approving the application of marketing libraries on a PHI containing site. I agree that there should be a lot more safeguards still, but the bug also being in place between 3-4 years suggests to me that it was a lot more subtle than just "don't include `ads.google.js` on the patient's medical history page". It's possible they really are just completely inept and haven't had any audits in 5 years but we won't really know that unless/until someone leaks more details.