Michael Page Recruiting Breach Caused By Operations Error – 750,000 People Affected

Michael Page/ The Page Group is a family of international recruiters operating in 35 countries and employing over 5,000 people and based in the United Kingdom.

Like many companies, PageGroup outsourced at least part of their IT operations;  in their case to another huge firm, CapGemini.

Earlier this month, Troy Hunt (a Microsoft MVP and regional director) was contacted by someone who shared this screenshot below with him (click to enlarge):

Index of backups of web site

For those of you who are not geeks, this appears to be a list of backups of a number of SQL databases for a range of countries.  The source sent a small file to Troy (about 350 meg compressed) which expanded to almost 5 gig.  Extrapolating the rest of the files, this represented about 30 gig of data.

One table in that database had fields called first name, last name, current job, location, current salary, telephone and other information.  This got Troy’s attention as he communicated with his source, he found out that the server where this data lived was at CapGemini, the mega international consulting firm with almost 200,000 employees in 40 countries.  Surely a firm as big and professional as CapGemini would not leave data like this exposed to the Internet.  Except that they did.

Troy, being an executive at Microsoft, had contacts at CapGemini and when Troy called, he told his contact “you are about to have a very bad day”.  That turned out to be an understatement.

The PageGroup released a FAQ on the breach (available here) talking about the breach and how it really wasn’t that bad.  In the grand scheme of nuclear war and global famine, that is absolutely true.  But to 750,000 plus people who’s information was compromised, that is probably not a great relief.

One more time, this is an example of a company (the PageGroup) being done in by one of it’s vendors (CapGemini).

The server was a TEST server – used to test new web sites.  The data, however, was not test data.

Lesson #1 – don’t use REAL data as test data.  A 12 billion euro company like CapGemini can invest in technology to create bogus test data so that they don’t have to risk the compromise of a client’s real data.  In the financial sector, where I worked for a long time, you can get fired for testing with real data.

But using real data was not the problem.

Some enthusiastic operations person figured we better back up this data and did.  Unfortunately, those backups for some reason, were stored on a server exposed to the Internet.

Lesson #2 – Be careful where you put backups.  The public Internet may not be the best place.

Lesson #3 – Encrypt backups and do not leave the key on “under the doormat” so to speak.  If these backups were encrypted with strong encryption and the keys not stored with the data, we would not be having this conversation.  If CapGemini was not encrypting their own backups, were they encrypting the backups of their clients?

Even though this is an operational error, I suspect there are some “interesting” conversations taking place between executives at the PageGroup and executives at CapGemini.

It is unclear what the contract between the two companies says about security, but lesson 4 is:

Lesson #4 – Make sure that you have a vendor risk management program, that you audit your vendor’s security practices and that your contracts hold vendors responsible for their blunders.

While the 750,000 people affected are probably not happy, it could have been a lot worse.  What WE don’t know (CapGemini may know) how long the data was out there and how many people other than the one who reported it to Troy downloaded it. Could be no one, could be many people.  The data may have been out there for years – we don’t know.

For everyone else, there is a lesson to learn here.

Information for this post came from Troy Hunt’s blog and The Inquirer.

[TAG:BREACH]

by