Handling Data Breaches, Or: The Art of Fixing and Saying “Sorry”
The frequency in which data leaks and breaches appear makes it easy to forget how severe some of them are.
It seems like every 2 days we hear about a new data breach; we’ve got people like Troy Hunt who keep blogging about them and we’ve got services such as HaveIBeenPwned (belongs to Troy) to notify people about breaches which contain their email inside the leaked data.
Most if not all of the breaches are unjustified. They don’t involve sophisticated hacking abilities. They are often made possible by random IP/Port scanning, automated tools (ran by what’s known as “Script Kiddies”), or even public sites dedicated to indexing and finding exposed services and devices, such as Shodan.
And sometimes the human error that caused a data breach is beyond ridiculous; it’s sheer ignorance.
Back in October 2016, the Internet got crazy again, that time was about a database of donors, belonging to the Australian Red Cross Blood Service, which had leaked and contained super-sensitive donor information. The Australian Red Cross Blood Service plays a very important role in maintaining a stable bank of blood products (whole blood, plasma, platelets donations and the like) and it’s a shame that this had happened to them. That breach was sensitive to many Australians, especially as many of them (including myself) are regular blood donors.
Before going any further, for those of you who haven’t read it, I encourage you to read the full leak report by Troy Hunt. To summarize what happened: A database full of blood donors’ personal information, including answers to sensitive questions, was exposed on the Internet. Meaning, you could have just browsed to a publicly open IP address and get it. An honest and decent person discovered it, notified Troy Hunt who then notified the appropriate authorities and things then got resolved promptly.
This was not the Australian Red Cross’ fault, at least not the technical one, and actually, the Australian Red Cross’ response was outstanding. They communicated it in a very transparent way straight after — they sent emails to all of the people who were affected, and their CEO Shelly Park faced the media and sincerely apologized for what happened and took ownership on behalf of the Australian Red Cross Blood Service for the fault, even though it was not theirs. They even created a website dedicated to that — info.donateblood.com.au which currently redirects to another page inside their main domain, explaining about their new data protection policies, which is really good and thorough, and shows that they have taken this incident really seriously. This was the page before the redirect. Read it. It’s good — seriously. I wish everyone was so upfront and transparent as the Australian Red Cross Blood Service and its CEO Shelly Park.
The culprit of this breach was one of their providers, a company named Precedent, which originally had this database for legitimate reasons (mainly — allowing donors to book appointments online, as they were the contractors that maintained the front-facing website and its appointment booking system) but suffered an unforgiving negligence by one of its personnel who, allegedly, put a database backup file on a publicly-accessible web server that had no password protection and that had Directory Browsing enabled (directory browsing allows you to see all the contents of a folder without needing to guess file names, basically).
So why do I write about it now, 5 months after? What’s the news?
The news is that there’s no news from the real owners of this blunder: Precedent.
When the news about the breach flooded the media, they seem to have tried to minimize damage as much as they could. They only released one official response on one page of their site and you couldn’t get much more info from them. That page itself refers to the Australian Red Cross Blood Service website for more information. Needless to say, the word “sorry” was absent from their message.
At the time, I contacted Precedent with a series of questions. I sent them these questions in several ways and got no response from them. I called them, talked to several of their people — they promised to reply with some answers — and they failed to do that until this very day.
These are the questions I asked them:
1. Was all of the data in that database entered by people on the website you maintain, or was all (or some) of it given to you by the ARCBS?
If it was all entered by people on the website: does it mean that people who never used the site to book appointments do not have their personal details on that database file?
If all (or some) of it was given to you by the ARCBS, which fields were given by them?
2. Since the file was available on a publicly accessible HTTP (or FTP?) service with directory browsing enabled, it’s also quite reasonable to assume site logs were enabled. Did you scan the logs to check whether there were GET requests for this database? there will be at least 2 I suppose: one by the person who discovered it and one by Troy Hunt. But were there more? Please provide details about those occasions (mainly time and IP address).
3. I understand that the file was located on an individual person’s desk PC. Is this correct? how come there was no perimeter security that blocks the internal network from outside access?
4. How did that backup file end up under a web-served folder, rather than any other reasonable location on disk?
Since I have received no answer from Precedent til now, one can only conclude/guess what the answers are.
As a side note, another interesting anecdote is that Precedent seem to have deleted articles about Australian Red Cross Blood Service as their customer. For instance this random post on their site that has a Related Articles section:
The middle box links to this page: www.precedent.com/our-work/australian-red-cross-blood-service which is currently broken:
Could it be that they try to minimize associations of their name to the Australian Red Cross Blood Service, or otherwise, or perhaps the Australian Red Cross Blood Service asked them to remove any affiliation? I don’t know.
The bottom line here is that Precedent reflect a symptom which many breached companies suffer from: minimizing damage by minimizing media response, and refraining from saying “sorry”.
Lesson to companies
It seems like copy-paste clichés don’t mean much these days. A company might say “We are taking the matter extremely seriously” but this might be marketing and PR only. I’m not sure companies follow that with serious, active efforts to enforce security and privacy policies amongst their staff members. Security costs and staff awareness programs don’t yield short term profit, so they are often pushed down and never prioritized. In addition, once you’ve messed up, face the public and say “sorry”. Precedent’s radio silence beyond their initial response is puzzling.
We are here to remind: security and privacy malpractices will not be tolerated by those who were affected and by the greater Internet community.
If you cut your organization’s costs by neglecting security, if you’re minimizing damage by not saying “sorry” and truly explain how you’re going to change your practices, we will remind that it doesn’t pay off.
Originally published at fullstack.info on March 27, 2017.
