The Red Cross Blood Service: Australia's largest ever leak of personal data(troyhunt.com)
troyhunt.com
The Red Cross Blood Service: Australia's largest ever leak of personal data
https://www.troyhunt.com/the-red-cross-blood-service-australias-largest-ever-leak-of-personal-data/
31 comments
This is exactly why large stores of data should be considered a liability and NOT an asset. Keep as little of it as possible and for the least amount of time possible.
I'm actually a bit confused about why they would need to store the medical test data and medical questionnaire information at all - can't you boil those down to "suitable" and "not suitable"?
I'm actually a bit confused about why they would need to store the medical test data and medical questionnaire information at all - can't you boil those down to "suitable" and "not suitable"?
One would imagine a case where some blood product recipients got sick after a transfusion, and the data would be helpful to narrow down the cause relative to donor histories.
I bet you could encrypt all the histories with a public key however, and only decrypt in such cases: private key held in a safe in the director's office, etc.
I bet you could encrypt all the histories with a public key however, and only decrypt in such cases: private key held in a safe in the director's office, etc.
You are absolutely on the money here, however, as a rule it seems companies and their management feel that more data equals more power and potential income and so they are loathe to discard anything, even long after it has lost all value except to an attacker.
> This is exactly why large stores of data should be considered a liability and NOT an asset.
Your comment reminded me of a post by Bruce Schneier with a similar theme, called "Data Is a Toxic Asset" [0].
[0] https://www.schneier.com/blog/archives/2016/03/data_is_a_tox...
Your comment reminded me of a post by Bruce Schneier with a similar theme, called "Data Is a Toxic Asset" [0].
[0] https://www.schneier.com/blog/archives/2016/03/data_is_a_tox...
> All of my experience in the field tells me that they were better protected than the vast majority of organisations of their size.
Which is a nice tell on what's going on elsewhere without having direct insight.
Which is a nice tell on what's going on elsewhere without having direct insight.
One point I take away is that there's something even better than "responsible disclosure": talk to your local CERT instead of the company affected, unless you trust the company will handle it professionally.
It seems plausible that big organisations might take the contact from an individual as "I haz ur data, omg Haxor!", then call the police.
Whereas the approach from a local CERT agency is likely to be taken more seriously, acted on more speedily, and possibly result in less blowback on the individual who came across the information and reported it.
Whereas the approach from a local CERT agency is likely to be taken more seriously, acted on more speedily, and possibly result in less blowback on the individual who came across the information and reported it.
One point I take away is, the more data there is, the more costly it is to secure it with procedures. Hence, we should require an insurance every time we collect and merge data, and start hugely increase the fines, just to make sure insurances will be requiring the right procedures.
Or, you know, just don't keep the data.
Or, you know, just don't keep the data.
"That 1.74GB was simply a mysqldump file that had everything in it... The database backup was published to a publicly facing website."
This cements my opinion that we need sysadmin licenses.
As a sysadmin myself, when I read that in the article, I physically cringed. No wonder you can't trust anyone with your private data these days!!
This cements my opinion that we need sysadmin licenses.
As a sysadmin myself, when I read that in the article, I physically cringed. No wonder you can't trust anyone with your private data these days!!
It's bad, but I've seen worse. Much worse.
I'd be curious to hear some anecdotal stories like this, would you share :)
I'd love to, however the penalties on breaking the NDA's are somewhat higher than my net worth, and besides my reputation and continued employment is worth more to me than satisfying the curiosity of your average forum visitor.
That said, the insights I've gained over the last couple of years have made me very wary about anything stored in databases concerning myself and the rest of the general public.
Let's just say that Snowden only exposed the tip of the proverbial iceberg and that one day the truth will likely come out because of some horribly insecure entities being hacked (if it hasn't already happened) with massive exposure of people in positions of power as a result.
The more you look behind the curtain the longer you are amazed that it is still being held up.
That said, the insights I've gained over the last couple of years have made me very wary about anything stored in databases concerning myself and the rest of the general public.
Let's just say that Snowden only exposed the tip of the proverbial iceberg and that one day the truth will likely come out because of some horribly insecure entities being hacked (if it hasn't already happened) with massive exposure of people in positions of power as a result.
The more you look behind the curtain the longer you are amazed that it is still being held up.
all right, all right, thanks anyway
I'm not jacquesm, but one I always like to share is a client who would store credit card data - numbers, addresses, expiration dates, and cvvs (yes) - in plain text in a database, in plain violation of PCI compliance and common sense.
We kept telling them that this was a bad idea, that it wasn't compliant, that it was dangerous, that they could lose their ability to process credit cards at all at best, and lose their entire database of customer credit card numbers at worst.
But there was no money in the budget for this kind of refactoring.
Until the data was exfiltrated via a trojan.
Suddenly, there was money in the budget.
We kept telling them that this was a bad idea, that it wasn't compliant, that it was dangerous, that they could lose their ability to process credit cards at all at best, and lose their entire database of customer credit card numbers at worst.
But there was no money in the budget for this kind of refactoring.
Until the data was exfiltrated via a trojan.
Suddenly, there was money in the budget.
>Suddenly, there was money in the budget.
Was this before or after the lawsuit? Assuming there was one (which there really needs to be...)
Was this before or after the lawsuit? Assuming there was one (which there really needs to be...)
> Suddenly, there was money in the budget.
But the horse had already bolted.
But the horse had already bolted.
I got a text message from the RCBS notifying me of the breach as I was reading the article describing it (already knowing that I was likely someone affected as a person who has regularly donated and participated in university challenge drives) followed by an email. Felt their disclosure and follow up has been appropriate although obviously disappointing they so sloppily allowed data to be left around on servers.
Was interested to read that there is a security body Australian Cyber Emergency Response Team (AusCERT) to deal with this stuff
- this is the link the text message sent me to: http://info.donateblood.com.au/
Was interested to read that there is a security body Australian Cyber Emergency Response Team (AusCERT) to deal with this stuff
- this is the link the text message sent me to: http://info.donateblood.com.au/
It's worth reading the entire article and comments - very interesting. I particularly like the bit at the end discussing the ethics of the recovery - I can't decide if it is ethical or not...many sides to the issue.
The official statement http://info.donateblood.com.au downplays what was disclosed. "Included in the file was information such as names, addresses and dates of birth."
That's kind of different to the confidential questionnaire answers.
Seems a bit incompetent why any of it is near a webserver - they don't have an "online profile login" or anything like that.
That's kind of different to the confidential questionnaire answers.
Seems a bit incompetent why any of it is near a webserver - they don't have an "online profile login" or anything like that.
You can book appointments to donate blood on the public web site. The questionnaire is part of that process.
Ah right. That makes a bit more sense, I thought Troy meant the paper answers ended up on the webserver.
I guess I was thinking the online presence was more like a "contact us" email form that emails it somewhere internal, not stored on the server.
I guess I was thinking the online presence was more like a "contact us" email form that emails it somewhere internal, not stored on the server.
+1 to Troy, this blog is amazing. The blog posts are always on point technically and ethically.
Why hack a blood service system at first place? Oh my. Not that people should hack anything, but this is extra nasty.
They didn't. They scanned the IPv4 address space for servers with directory listing enabled and ".sql" files visible, and happened to find one at Australia's red cross.
And if you're less technically inclined, you can bypass the whole manual scanning of address space, and just look at what Google's already indexed publicly for you:
https://www.google.co.uk/?q=%22index+of%22+.sql
https://www.google.co.uk/?q=%22index+of%22+.sql
7000 entries :(
The article says that the system wasn't hacked so much as a database backup was left on an unsecured, public site and was discovered. It seems plausible, from the described timeline of events, that the discoverer didn't know what they had until they had downloaded and examined the data.
What kind of sucks here is that there's a complex chain of trust from donors to medical staff that take the donations and process the paperwork to a computer technician that for whatever reason exposed the data to the world. Everyone involved in that kind of medical activity has to have an intense and professional respect for patient dignity. The thing that sucks is you could look at this data and realize that due to the actions of a nameless computer janitor, the assurance you gave to people whose blood you took about the privacy of their participation is worthless.
The other thing that sucks is to think about the kind of care that you should take, as a computer janitor, with this kind of information. Seven million data points about things as sensitive as "at-risk sexual behavior" correlated with full names and addresses? How do you even process how careful you should be? I would have three different people double check everything I did! I would go to sleep every night paralyzed in fear that I made some tiny mistake!
Okay, as an aside, when you're designing IT systems and data storage policies for research, your ethics and review people wouldn't let you do this. More specifically, in my (collective) experience, it seems very, very unlikely that a research institutions ethics review board would let a researcher store data given in confidence associated with non-anonymous identifiers in a computer system. Usually, they ask that you don't even link identifiable information (which you need to record that you received consent) with results. They should be totally separate. And for "high-risk" data, they would ask that the consent data not even be stored electronically (one reason: you might think that data collected "for science" is in some way exempt from disclosure to say, law enforcement. It isn't. So if you want to do research about say, drug use in pregnant and nursing mothers, you are literally gathering evidence about crimes that the police could use to prosecute your research subjects. Don't harm your research subjects - make the data that you store, the data that the police could seize with a warrant, useless for that purpose).
Anyway, IMO, it seems a failure here is that someone at RC sat down to make a DB schema and didn't see a problem with having fields like "Legal name" and "Permanent address" in the same table (or even system!) as fields like "have you engaged in at-risk sexual behavior." There are safeguards in other fields against even making systems that correlate this kind of information. Why aren't they present here?
What kind of sucks here is that there's a complex chain of trust from donors to medical staff that take the donations and process the paperwork to a computer technician that for whatever reason exposed the data to the world. Everyone involved in that kind of medical activity has to have an intense and professional respect for patient dignity. The thing that sucks is you could look at this data and realize that due to the actions of a nameless computer janitor, the assurance you gave to people whose blood you took about the privacy of their participation is worthless.
The other thing that sucks is to think about the kind of care that you should take, as a computer janitor, with this kind of information. Seven million data points about things as sensitive as "at-risk sexual behavior" correlated with full names and addresses? How do you even process how careful you should be? I would have three different people double check everything I did! I would go to sleep every night paralyzed in fear that I made some tiny mistake!
Okay, as an aside, when you're designing IT systems and data storage policies for research, your ethics and review people wouldn't let you do this. More specifically, in my (collective) experience, it seems very, very unlikely that a research institutions ethics review board would let a researcher store data given in confidence associated with non-anonymous identifiers in a computer system. Usually, they ask that you don't even link identifiable information (which you need to record that you received consent) with results. They should be totally separate. And for "high-risk" data, they would ask that the consent data not even be stored electronically (one reason: you might think that data collected "for science" is in some way exempt from disclosure to say, law enforcement. It isn't. So if you want to do research about say, drug use in pregnant and nursing mothers, you are literally gathering evidence about crimes that the police could use to prosecute your research subjects. Don't harm your research subjects - make the data that you store, the data that the police could seize with a warrant, useless for that purpose).
Anyway, IMO, it seems a failure here is that someone at RC sat down to make a DB schema and didn't see a problem with having fields like "Legal name" and "Permanent address" in the same table (or even system!) as fields like "have you engaged in at-risk sexual behavior." There are safeguards in other fields against even making systems that correlate this kind of information. Why aren't they present here?
I'm in the early stages of planning a system that holds medical data as a side project and the security aspect is giving me real pause about going ahead, I just don't know if I can reach a level of security I'm comfortable with while allowing users to enter that kind of data.
The existing standards are mostly crap and I'm a generalist not a security expert.
The existing standards are mostly crap and I'm a generalist not a security expert.
We've done a few patient management platforms; feel free to reach out to me if want to bounce ideas - they're not as hard as you think, and you can generally find an acceptable balance between encryption / security / safety, effort & usability. Your local gov\medical board will also have guidelines available of standards you need to adhere to when handling confidential patient data over the wire; most of these docs are pretty old school but can be adapted easily with modern libraries and practices.
The harder bit is keeping nefarious actors out when they're determined to get in, and the hardest bit is user carelessness.
The harder bit is keeping nefarious actors out when they're determined to get in, and the hardest bit is user carelessness.
Thank you, I might just do that.
I'm in the UK but I've found the american standards often more informative as a guide when it comes to just getting an overview.
I'm in the UK but I've found the american standards often more informative as a guide when it comes to just getting an overview.
An outsider might suspect that this occurred because ARCBS is the sort of organisation that simply doesn't have the speciality/budget/staff required to manage data security properly, but this isn't the case by any means. My retrospective impression is that they had capable teams covering data warehousing, data security policies, network security, etc. All of my experience in the field tells me that they were better protected than the vast majority of organisations of their size.
This event has solidified some of my more apocalyptic thoughts w.r.t. info-sec. Namely, that a guarantee of secure data is essentially out of reach for almost any organisation of any size. Partly this is due to increased connectivity of networks, but equally it is due to better tooling and analytics staff making thorough organisation of customer data the norm.
The cause of this problem is the hoarding of knowledge, as Zhuang Zhou realised two and a half thousand years ago:
> In taking precautions against thieves who cut open satchels, search bags, and break open boxes, people are sure to cord and fasten them well, and to employ strong bonds and clasps; and in this they are ordinarily said to show their wisdom. When a great thief comes, however, he shoulders the box, lifts up the satchel, carries off the bag, and runs away with them, afraid only that the cords, bonds, and clasps may not be secure; and in this case what was called the wisdom (of the owners) proves to be nothing but a collecting of the things for the great thief.