Sophos Cloud Optix
Back in November 2013, telecomms company Orange signed a data protection charter.
Point one of the charter committed to protect the “security of customers’ personal data through its reliable processing and secure storage.”
But by February 2014, Orange was in the news for letting some 800,000 user database records slip, apparently including names, emails, phone numbers and hashed passwords.
And it seems it’s happened all over again, this time excluding the hashed passwords, but including customers’ dates of birth.
Current reports put the size of the latest breach at 1,300,000 records.
It seems that the data wasn’t stolen from one of Orange’s primary databases, but from an ancillary system used for sending promotional emails and text messages.
This highlights the problem that companies have when trying to vouch for security right through the business.
They have to make their promises on behalf of every programmer, of every IT staffer, of every server.
In fact, thay have to make their promises on behalf of every user, and of every device.
Indeed, they pretty much have to make their promises transitively on behalf of every contractor, service provider, marketing team, PR consultant, penetration tester, or other third party who might be entrusted with some or all of that data at any future time.
And channelling off data from core company databases for use by third parties – including other departments in your own company – always increases risk, because each time data is extracted and saved elsewhere, you have one more copy of that data to worry about.
Simply put you need to be able to answer the questions, “Do you know where your data is? Do you know who can get at it?””
Not knowing the answer to those questions could come back to haunt you, as happened twice over to Orange.
I agree with every one of your points, of course, but one must ask why the entire database was copied to this ancillary system when all they needed was a subset starting (and ending?) with email address and phone number. Why a customer’s date of birth should be copied I cannot imagine. If they need to know whether the customer is in a particular age band then why not re-code the data in a manner that won’t mean anything to anyone else. I hope the Data Commissioner is paying attention to this breach.
I write this with feeling – I’m an Orange customer!
I agree.
Including email address and phone number can be justified on the grounds of knowing where to send the messages. But the only reason I can think to include DOB is in case some of the promotions are age-restricted. In which case, why not [a] check first and export only a list of qualifying customers [b] include some kind of flag that indicates if the person is “over 18”, “over 16”, whatever is needed for the promotion, or [c] at worst, include “age in years.”
You don’t need to know that someone was born on the Fourth of July to determine if they are over 18.
Errrm, yes you do need the whole date of birth. On the third of July you could be 17 and on the 4th of July 18
If you are a database, you don’t need to know my birthday to determine that I am 18. All you need is a field called “RU18” containing the value “Y” or “N.”
In other words, you need my birthday at some point to compute my age in years; thereafter, you only need to remember that I passed your age check at some point, so you can throw away my birthdate.
If I’m a database and I just have a RU18 column then my developer was either a novice or paranoid… because now I would need to have a daily job that runs and updates the pertinent RU18 column for people who turned 18 today. (just imagine the process if we were professional enough to handle if someone has turned 18 in another timezone… but would technically be 18 in ours!)
…or I could write one clause to see if someone’s DOB was more 18 years ago.
Should there be a RU21 field too? How about RU30 if we want to target people in that age bracket? If we did, this would be kind of a reckless database design.
Sorry but there is a good reason to have a DOB.
It sounds like this data was extracted from the main database to support a marketing campaign. In that case you only need a flag indicating whether the customer is 18, or even better only include customers who are at least 18 on the extracted data. Typically once the marketing campaign is over the extracted data is deleted. For the next marketing campaign you create a new database extract.
Indeed. But perhaps the idea was that the marketing server would have enough data channeled off to do some “autonomous” campaigns in the future…
An RU18 field should be quite good enough for the likely lifetime of the data used in a marketing run. (The channeled-off database with the RU18 field needs regenerating on a regular basis anyway, for example to remove the entries of people who have opted out.)
As for targeting people in an age bracket…well, you really don’t need birth*date* to do that. Year alone would be enough.
The Orange icon above would seem to indicate folks are trade-marking colors. How does that work? Is blue already taken?
Not the color. The entire symbol, an orange square with white lower-case text at the bottom, reading “Orange” tm. Probably restricted to where the ratio of text height/length to a square-size must be within a small fixed range.
Also, Trademark is different to copyright.
Orange is Trademarked as a company name – another company cannot come along and call themselves Orange, but you are perfectly free to use the word in any other way.
The logo probably is copyright, but that’s a pure guess.
(Not a lawyer:- must get my excuse in before someone tells me I’m utterly wrong 🙂 )