The Past, Present and Future of Database Security
In 2006 there were 335 publicized data breaches in the U.S. So far in 2007 there have been 276. With the 5th anniversary of the SQL Slammer worm drawing near, now is a good a time as any to look back on the past of database security and ask how far have we come since then and is our data any more secure today? And what of tomorrow? How will our database systems fare in a world of emerging threats? Have we learned our lesson or will we be consigned to the graveyard of statistics?
Guess?, Inc, 3rd March 2002
In the February of 2002 a security aware customer, Jeremiah Jacks, whilst using Guess Inc’s website discovered it was vulnerable to SQL injection. He found that he could trivially gain unauthorized access to 200,000 customers’ credit card details. After failing to get Guess to fix the problem Jacks contacted SecurityFocus.comto enlist their help. Within an hour Guess had resolved the problem with company spokeswoman Jennifer Munakashclaiming, “It was an easy fix.” Indeed, when the Federal Trade Commission filed a complaint on 18th of June, 2003 it stated that “the risk of web-based application attacks is commonly known in the information technology industry, as are simple, publicly available measures to prevent such attacks.”. Guess settled the FTC charges on August the 5th, 2003.
TD Ameritrade, 14th September 2007
TD Ameritrade, a Nebraska based online trading company, announced on September 14th 2007 that one of its database servers had been compromised by a hacker exposing 6.3 million customer records. The breach came to light when a large number of TD Ameritrade’s customers started complaining about receiving investment based spam (“pump and dump” stock scams) causing the company to start an investigation. The investigation revealed that a hacker gained access to customer information such as their names, email addresses, snail mail addresses and phone numbers. The investigation concluded that no social security numbers, account numbers or dates of birth were taken despitedthe fact that such details were stored and available in the same database server. This case is interesting as it clearlyshows a targettedattack with a specific agenda. The hacker didn’t go after SSNs, etc (which would enable them to commit ID theft); they didn’t go after the clients’ assets (which could enable them to commit financial theft); they harvested email addresses of people known to engagein buying and selling stocks to target them with their spam stock scam program.
Practical quick hits
- Ensure your databases are protected by a firewall
- Deploy IDS/IPS
- Change default user IDs and passwords
- Encrypt customer data
- Audit database accesses
- Keep on top of patches
- Perform regular vulnerability assessments
- Pay close attention to SQL injection in web apps!
Author: David Litchfield
