What do recent well-publicized data breaches have in common? With the exception of lost laptops, purloined handheld devices, dumpster divers, or someone physically nicking a PC from the office, all breaches involve a common entity: the database.
"At least one-third of the more than 200 million personal records compromised over the last two years were taken from a database," says Ted Julian, VP of marketing and strategy for Application Security, citing data breach statistics from the Privacy Rights Clearinghouse. Furthermore, the frequency and severity of breaches is increasing. According to the Identity Theft Resource Center in San Diego, nearly four times as many Americans had their personal information stolen in 2007 as in 2006.
Don't let databases fool you. Sure, their names may sound stately (Oracle, Ingres) or innocent (MySQL, SQL Server, Sleepycat). Yet no database, just out of the box, is secure. In addition, because databases concentrate so much potentially lucrative information in one place, they're prime targets. "Databases are really where the crown jewels of the business are stored," notes Mark Bowker, an analyst at Enterprise Strategy Group. That applies regardless of a company's size.
Thanks to the scale of their operations, however, larger organizations do get more data breach limelight. In September, for example, Ameritrade disclosed a breach involving more than 6.3 million customers' data. Meanwhile, the TJX Companies -- owners of retail stores T.J. Maxx and Marshalls -- recently offered to settle a massive class action lawsuit arising from its improper storage of, and failure to secure, 45.7 million customers' credit card data.
While storing sensitive or regulated information puts any company at risk, smaller businesses may have more to lose. "For small businesses, the impact of data loss is much higher, because they have less infrastructure," says Mark Kraynak, senior director of strategic marketing for Imperva. "They probably don't have backups, and they don't have the organizational wherewithal or response teams to handle a big public breach, or getting sued."
How, then, can small and midsize organizations ensure their databases don't end up breaking the business? Experts offer 10 tips to secure your databases:
1. Know You're At Risk
Don't have a database containing sensitive information connected to the Internet? You're still at risk. Forrester Research estimates that 70% of all database breaches arise internally -- no Internet connection required. Unfortunately, detecting internal attackers can be quite difficult, especially because the person who poses the biggest threat is none other than the actual database administrator (DBA).
"DBAs are allowed certain amounts of freedom in their job, which makes a bad DBA hard to catch," notes Noel Yuhanna, an analyst at Forrester Research. In particular, "because DBAs have full access to all data within a database, they could potentially change or delete data without anyone knowing."
Thus for DBAs, and any other user with privileged access, ideally "you should have a secure way to record what they did, because you want to make sure they aren't doing things they shouldn't be doing," says Kraynak. Still, most database experts acknowledge that database monitoring tools are largely the domain of larger enterprises; small and midsize companies often need to focus on more basic issues first.
2. Prioritize Security
If DBAs are a security risk, their security habits also require scrutinizing. Indeed, Yuhanna estimates DBAs spend an average of only 7% of their time on database security.
The scarce attention paid to database security isn't such a surprise. "In an SMB, it's all about getting that application out, getting that database out, making sure it remains online and available, and maintaining proper performance," notes ESG's Bowker. "Unfortunately, security usually falls toward the bottom of the list."
Add database security to the DBA job description.
3. Enable Security Capabilities
Databases ship with virtually no security controls enabled by default. Indeed, most databases have weak authentication controls, and well-known default passwords, both for user and administrator accounts.
This is an improvement: some older databases -- notably Sybase and SQL Server -- didn't by default require a password for full database access, says Yuhanna. Today's databases, however, can natively handle what he terms "the three A's": authentication, authorization, and access control. Enable such capabilities.
4. Patch the Database
Before putting any data into a database, "check the patch level, look at the way it's configured, and see which defaults are potentially vulnerable -- ranging from default users to features that are turned on by default," says Krayak. "So you want to do an assessment on the database, and fix them -- which isn't as easy as it sounds."
For help, look to commercial database vulnerability scanning tools, or free options, such as Imperva's Scuba.
5. Restrict Database Access
Next, restrict database access -- both to the production database, as well as underlying hardware -- on a need-to-know basis.
Too often, administrator passwords are an "open IT secret," says Bowker, who pleads guilty from when he formerly ran a midsize company's IT shop. "Even with something as simple as the HR database, to be honest, all the IT guys had access to that, and could look up salaries and that type of information, just because we didn't have up-front controls, such as access restrictions to the machine the database was on."
Who gets administrator-level access privileges? For an organization with at least a few IT employees, he says, "typically one of them is responsible for the database and any copies, and you just have to put restrictions on the other operators, so they won't have the ability to go there and do anything." Also ensure database backups are only stored in encrypted format, so no one can surreptitiously access the data.
6. Prohibit Wholesale Database Copying
A production database typically has a designated owner or gatekeeper. Yet who watches a database after it's been copied? Simply put, any copy of a database will most likely be unsecured, and therefore "it's an internal threat," says Bowker. "The DBA, those types of people, they all have root access at that point, and can essentially read anything." Don't allow unchecked duplication of databases.
7. Inventory Existing Databases
Locking down databases out of the box and prohibiting wholesale duplication may sound fine, but what about securing databases and copies that already are at large?
Companies must regularly find and inventory all existing databases. Know that one production database may hide many copies. "Typically, in a lot of businesses, you have the production database, but guess what, that database usually has a lot of copies -- developers have copies, for example -- and many databases correspond and make calls to each other," says Bowker.
Large organizations often use automated discovery tools to find and continually monitor databases to ensure sensitive information isn't stored in unencrypted format. Experts say smaller organizations, however, will probably already know which databases contain sensitive information.
8. Secure Existing Databases
Use the database inventory to address the riskiest databases first. "With this information in hand, most SMBs will find that they can eliminate some [data], mask some, and so on, thus minimizing their exposure and at the same time simplifying the security improvements they need to make," says Julian of Application Security.
Also assess databases for known vulnerabilities and patch levels. "Once you've done that assessment, do it again every quarter, or periodically make sure you have a process to check this stuff, because things change," says Imperva's Kraynak.
Finally, study user accounts; Forrester estimates 30% of database accounts are duplicates, or inactive. To guard against disgruntled former employees, regularly purge inactive and duplicate accounts.
9. Scramble Shared Data
If companies restrict copies of databases from being made, how will developers get the data needed to develop and test new applications? How can sales managers train new agents on the customer relationship management system? For such cases, Bowker recommends using tools from companies such as Applimation, HP OuterBay, IBM Princeton Softech, or Solix Technologies, to subset the database.
Subsetting allows a DBA -- or whoever is the designated gatekeeper for sensitive data -- to selectively share parts of a database after first deleting, transforming, or faking any sensitive information, based on how the database subset will be used. Developers and testers, for example, may require fake data (such as credit card and social security numbers) that's still good enough (in terms of application logic) to stand in for the real thing.
10. Plan For Database Retirement
Finally, remember that databases won't live forever. "Databases do get retired -- or 'sunsetted,' if you want to use that term," says Bowker. Typically, this involves writing the database out in XML format, with tags, to facilitate later searching or satisfy retention requirements. As with all sensitive data, restrict access to these XML files.
The New Breakage Equation
Getting business managers to sign off on the above tips may require a change in attitude. "DBAs are generally given the mandate to make it work, and make it work fast," says Kraynak. "If it breaks, the business breaks, and if it's not going fast enough, essentially the business still breaks."
Now, just factor data breaches into that breakage equation.
Mathew Schwartz has covered IT and business topics for more than 10 years as a journalist, researcher, and editor. His work has appeared in a variety of publications, including the Boston Globe, Computerworld, Information Security Magazine, the London Times, IT Compliance Institute, and Wired News.