5 Steps For Good Database Hygiene

Some of the most important ways to reduce risk boil down to the fundamentals of security. Keep systems well-patched, prevent data from spreading around, make sure systems are properly segmented, and watch where you store valuable log-in data. Much like flossing, these good habits require day-to-day maintenance that will reap long-term benefits.

Here are what the experts say about the kinds of actions necessary to keep up on good database hygiene.

[Which applications and vendors dominated the vulnerability and exploit headlines in 2012? See The Vulnerability 'Usual Suspects' Of 2012.]

1. Apply Timely Patches
Just as patch and vulnerability management play a huge part in reducing risk on the endpoint, these basic fundamentals are just as important to keeping house within the database environment.

"Perhaps the easiest and most effective solution for securing databases, installing vendor patches as quickly as possible will help to mitigate threats due to known vulnerabilities," says John Linkous, chief security and compliance officer for eIQnetworks.

And yet this effective fix is frequently ignored by users. According to the 2012 IOUG Enterprise Data Security Survey released last week, 28 percent of Oracle users have never applied a Critical Patch Update or don't know whether they've done so. Another 10 percent take a year or longer to apply their patches.

In the same vein, developers that implement Web applications that connect to databases also need to patch more faithfully.

"Many developers implement a Web application and then forget about it. But Web applications are not 'set and forget.' Some components are part of a package that needs a maintenance regime to ensure it is not exploited," says Mark Goudie, managing principal for the RISK Team at Verizon Enterprise Solutions. "Too many organizations expect that the Web application has been implemented and treat it with the maxim of 'if it ain't broke, don't fix it.' There are people scanning for vulnerabilities 24 hours a day, every day. Don't give them a chance to compromise your systems. Patch what you can."

2. Prevent Production Data Creep
If your organization does a good job keeping its databases well-monitored and data within properly encrypted, don't undo all that work. It is crucial to make your policies conform to the Vegas tagline: What happens in the database, stays in the database -- because as soon as production data starts making its way into other places and formats, things tend to get messy and risk shoots sky-high. For example, organizations should be doing their best to avoid allowing live data make its way into test and development environments.

"Forklifting the production database into your test and development environment increases the risk of data privacy breaches, increases storage and CPU capacity requirements, and impedes flexibility and agility," Robert Catterall, an IBM DB2 specialist, wrote recently.

Similarly, stray spreadsheets on insecure endpoints that contain vast amounts of data imported from the database can effectively negate all of that investment spent on protecting the same data within the database.

And while it defeats the purpose of backing up to eliminate database backup files, it is important to keep a lid on where and how these files are stored.

"Be aware of where your database backup files get stored: Ensure they are not stored anywhere in the Web application root, or where they might otherwise be accessible to a Web application request," says Chris Weber, co-founder of Casaba.

3. Share Servers Carefully
According to the incident response experts at Verizon Enterprise Solutions, one of the frequent ways they see databases hacked is through shared Web servers.

"If there is one vulnerable Web application on the Web server and poor security implementation, then that single vulnerability in one website could mean a data breach for all websites and associated databases," Goudie says. "It's OK to share Web servers, but thought needs to be put into what data that server has access to. This is not just a once-off static analysis, but needs to be performed every time there is a change in the data accessed by the Web application as this may require the Web application to be relocated to a different security zone."

And even if Web servers can be shared, organizations should look to store the databases somewhere else.

"Separate Web and database server roles," Weber says. "Don't host both on the same machine; use strong authentication methods where possible [with] client certificates above passwords."

Even without the server-sharing issue, enterprises generally need to do a better job securing their database servers, says Rob Sobers, technical marketing manager for Varonis.

"The lion's share of security settings and risk reside on the server that hosts the database," he says.

Some of the things to think about on his checklist include looking at what inbound connections the server allows by default and whether the connection string is stored in a plain-text configuration file. That leads us to the last two items on our list.

4. Rein In Application Access
Within the typical enterprise, many application accounts are given entirely too much access to the database and, to make matters worse, those account details are often known throughout the organization by users who may take advantage of the superuser capabilities for legitimate and not-so-legitimate access purposes. But that's the problem: With shared application accounts, the access patterns are so messy they throw monitoring and policy enforcement all to heck.

Experts explain that enterprises have to get a better handle on how applications are accessing the database to prevent them from becoming an easy channel for attack from both insiders and external hackers.

"Enforce access-control lists for applications connecting to the database," says Toby Weir-Jones, head of portfolio marketing for BT Assure. "If you know that queries, insertions, and modifications should only originate from specific sources, build in ACLs to enforce them. Much like a firewall, the default behavior should be to block all connections except for those which are explicitly permitted.

5. Protecting Connect-String Configuration Files
All too often, developers store in plain text the connect-string information for the databases their applications tap into within a configuration file that includes account username and password. In really untidy situations where the database is sharing a server with the application, those files sit side-by-side right on the same machine.

"The danger of this is if the Web server is compromised, the database login information is easily revealed from the config file," says Steven Lowe, CEO of Innovator, who encourages organizations to encrypt those files to better protect valuable database log-in information. "Encrypting the connect-string may seem like overkill, but in the event that the Web server is compromised, it makes it more difficult for an intruder to gain access to the database."

Have a comment on this story? Please click "Add Your Comment" below. If you'd like to contact Dark Reading's editors directly, send us a message.