Opinion

Guardian jobs database attack demonstrates difficulties of database security

Job hunting is a tough job in itself - battling with 8% unemployment, rehearsing for job interviews, adding relevant yet interesting hobbies to your CV - and then you receive an e-mail from The Guardian's job site to say that your personal details may have been stolen in a "deliberate and sophisticated" attack, and advising you to register with the UK's fraud prevention service, CIFAS, writes Phil Neray, vice-president of security strategy at Guardium.

That is what happened to thousands of job seekers at the end of October. The personal data of more than 500,000 users was accessed and stolen from guardianjobs, one of the most popular job sites in Britain with more than ten million unique users. Managed by third-party job board software supplier Madgex, the cracked database contained names, e-mail addresses, covering letters and CVs. Other details, including passwords and financial data, were reportedly not breached.

Modern day criminals want our data: credit, financial, personal. There is a strong black market in each, and identity thieves are more inventive than ever. The annual cost of identity theft to the UK economy is estimated to be £1.2bn.

Widespread exposure

Every year we share more of ourselves online - a trend that is set to continue as we spend more money on e-commerce sites, share details of our lives across multiple social media platforms, and search for jobs online. Each time we do any of these things, we place our data and our faith in commercial databases - Oracle, Microsoft SQL Server, IBM DB2, Sybase, MySQL - and the overarching security measures taken by the businesses that own these databases.

While Scotland Yard's e-Crime unit gets on the case, the Guardian breach has alerted IT and security managers of the need to protect their user data and to consider data security from every angle.

Most have already spent time, money and valuable resources securing their network perimeters with firewalls and anti-virus software, and even protecting their laptops with hard disc encryption and DLP solutions. It is a necessary step, but one which can also be guilty of generating a false sense of security.

SQL vulnerability

So how was The Guardian's data accessed? Well, all fingers point to an SQL injection vulnerability, a method currently in favour with hackers and data thieves. SQL injection attacks exploit vulnerabilities at the web application layer to access sensitive data in back-end databases. These web-based attacks pass undetected through firewalls and other perimeter defences, including intrusion detection and intrusion prevention systems, then hijack the application server to gain access to underlying database records.

This threat is rising. In 2008, the number of SQL injection attacks leapt by a staggering 134% to several hundred thousand occurring each day. And according to a data breach report published by the Verizon Business RISK team, 75% of all breached records came from compromised database servers, while other IT assets such as laptops and back-up tapes accounted for less than 0.05% of compromised data, and a staggering 90% involved groups identified as engaged in organised crime.

Yet databases remain vulnerable. Which prompts the question, just how many organisations are still open to this type of attack? And how many organisations do not understand that they are at risk?

Continuous monitoring

Until recently, identifying unauthorised or suspicious access to databases was impractical and complex. Logging all activity in the database itself significantly degrades system performance, while at the same time generating massive amounts of transaction records, which creates a "needle in the haystack" problem since all of the monitoring data must then be analysed and filtered to identify anomalous activity, typically using home-grown scripts.

But a new class of database monitoring appliance has emerged during the past few years that continuously monitors and analyses all database activities in real-time, from outside the database, without impacting database performance.

These systems, which can also be implemented as virtual appliances (software-only), mitigate the risk of external and internal attacks by immediately identifying suspicious behaviour based on automated policies and continuous comparisons to baselines of normal activity. They also simplify security and compliance by providing a single, integrated solution for heterogeneous environments.

Big responsibility

But why access The Guardian's job site at all? The answer is the first rule of hacking: because somebody discovered that they could. It may be argued that the theft of names, e-mail addresses, CVs and cover letters is relatively unimportant, almost unthreatening. Not so - data thieves are creative. Consumers who value the security of their personal data enough to rush out and buy shredders may not lose personal data from a rubbish bin, but does that matter if it is there for the taking online?

The definition of sensitive data has broadened. Dates of birth, addresses, personal histories, details of daily lives - all this data is useful to a fraudster, and may be the first steps towards more complete identity theft. Businesses have to understand that any and all personal data is valuable, and that it is imperative that they ensure the public has unshakable faith in their data storage.

A deliberate attack that resulted in the theft of half a million personal records from a very high-profile organisation is not to be sniffed at. Any enterprise that holds any personal data needs to take every step to safeguard it. But it is not an easy job - just ask The Guardian.

Email Alerts

Register now to receive ComputerWeekly.com IT-related news, guides and more, delivered to your inbox.
By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy

This was first published in November 2009

 

COMMENTS powered by Disqus  //  Commenting policy