Application Security // Database Security
2/5/2013
09:08 PM
Connect Directly
RSS
E-Mail
50%
50%

Backup Databases: The Data Security Achilles' Heel

The same sensitive information on production databases resides on backups -- protect them accordingly

If production databases contain regulated information or valuable intellectual property, then it follows that backup copies of those data stores carry the same risky information. And yet, while many organizations spend the time and investment in hardening live databases, they frequently fail to adequately protect their backup databases.

"So many people invest heavily into ruggedizing a database and spend little time tracking where their backup data goes," says Ken Pickering, development manager of security intelligence at Core Security. "A breach of critical information can occur just as easily from a backup file as it can from the production database."

It's a common scenario that plays itself out at countless organizations large and small, says John Mensel, directory of security services at IT service provider Concept Technology, who says his firm frequently sees customers making the mistake.

"A lot of companies have databases that contain things like credit card information, and yet they just leave those backups hanging out wherever anyone can get at them," Mensel says. "It's really simple to secure them, but it's often overlooked because of laziness or a lack of a sense of urgency about protecting them."

"Just as organizations calibrate production database protection based on the risk and compliance priorities around the data contained within them, backup databases should be secured in accordance with the sensitivity of the information they contain," says Dr. Stan Stahl, president of Citadel Information group, an infosec management firm, and president of the Los Angeles chapter of the Information Systems Security Association (ISSA).

[Wish You Could Tell Your CEO 'I told you so'? You're not alone. See Airing Out Security's Dirty Laundry.]

So any backup databases containing personal healthcare information have to live up to HIPAA and HITECH standards, for example.

"The only 'good enough' solution is one that protects sensitive information in accordance with applicable laws and regulations, the company's competitive opportunities, and its fiduciary responsibilities," Stahl says.

Paramount to the backup database protection plan is an adequate encryption mechanism.

"Encrypt, encrypt, encrypt. It is important to implement granular encryption that will encrypt the data and not just the database," says Tsion Gonen, chief strategy officer for SafeNet. "That way, if data is stolen, it is rendered useless."

But at the moment, not even a quarter of organizations encrypt all of their database backups, according to the 2012 IOUG Enterprise Data Security Survey. Just less than half either don't encrypt backup databases at all or don't even know whether they encrypt any backup databases.

This inconsistent application could come down to logistics. Sometimes simple full-disk encryption may not be an option. For example, backup databases on the cloud could pose special issues, says Fred Thiele, COO of consultancy Laconic Security, who explains that the Amazon AWS relational database service (RDS) allows administrators to snapshot databases and store them for quick restores. But the caveat is there's no option to encrypt the snapshots.

"So if you're not doing field- or column-level encryption on your database, the data your snapshots [are] in [reside in] Amazon-land in plaintext," Thiele says. "Same with their 'backup to point in time.'"

That is why organizations should consider field- or column-level encryption, even for databases, he says. Even outside of the cloud, an organization's disaster-recovery processes may stand in the way of simpler encryption mechanisms. In critical systems with little margin for downtime -- often the very same systems that contain the most sensitive information -- IT is pressed into configuring backups for rapid recovery in the disaster situations.

"In order to maximize the recovery time objective (RTO), a standby copy of all data and their applications may be stored in their native format in a secondary location," says Josh Mazgelis, senior product marketing manager at Neverfail, a disaster recovery and business continuity management firm. "Recovering data from an encrypted and deduplicated backup takes time, so short RTO requirements mandate the data be stored in its ready-to-use native format."

In these scenarios, if the data and the surrounding environment is exactly the same as production, then the same exact protections need to be put in place around them, Mazgelis says.

"User access control lists in the disaster-recovery copy will usually be identical to production due to the nature of the disaster-recovery replication, but don't assume this is always the case," he says. "Instance-level or storage-based replication will usually provide this, but database or record-level replication can easily move information into a less-secure environment."

Mazgelis also warns that one concern about backup databases could play more of a factor than with production databases, and that is the issue of physical security. Depending on the backup medium, disaster-recovery copies face the additional risks posed portability. Tapes fall off the backs of trucks all the time, so security strategy needs to account for this factor.

"Even encrypted copies can be compromised once a hacker has access to the physical copy. Be mindful of storage media when it is retired," he warns. "Old tapes and old hard drives may contain old data that can be valuable to all wrong people. Old media should be properly wiped or physically destroyed."

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.

Comment  | 
Print  | 
More Insights
Register for Dark Reading Newsletters
Partner Perspectives
What's This?
In a digital world inundated with advanced security threats, Intel Security seeks to transform how we live and work to keep our information secure. Through hardware and software development, Intel Security delivers robust solutions that integrate security into every layer of every digital device. In combining the security expertise of McAfee with the innovation, performance, and trust of Intel, this vision becomes a reality.

As we rely on technology to enhance our everyday and business life, we must too consider the security of the intellectual property and confidential data that is housed on these devices. As we increase the number of devices we use, we increase the number of gateways and opportunity for security threats. Intel Security takes the “security connected” approach to ensure that every device is secure, and that all security solutions are seamlessly integrated.
Featured Writers
White Papers
Cartoon
Current Issue
Dark Reading's October Tech Digest
Fast data analysis can stymie attacks and strengthen enterprise security. Does your team have the data smarts?
Flash Poll
Video
Slideshows
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2012-2413
Published: 2014-10-20
Cross-site scripting (XSS) vulnerability in the ja_purity template for Joomla! 1.5.26 and earlier allows remote attackers to inject arbitrary web script or HTML via the Mod* cookie parameter to html/modules.php.

CVE-2012-5244
Published: 2014-10-20
Multiple SQL injection vulnerabilities in Banana Dance B.2.6 and earlier allow remote attackers to execute arbitrary SQL commands via the (1) return, (2) display, (3) table, or (4) search parameter to functions/suggest.php; (5) the id parameter to functions/widgets.php, (6) the category parameter to...

CVE-2012-5694
Published: 2014-10-20
Multiple SQL injection vulnerabilities in Bulb Security Smartphone Pentest Framework (SPF) before 0.1.3 allow remote attackers to execute arbitrary SQL commands via the (1) agentPhNo, (2) controlPhNo, (3) agentURLPath, (4) agentControlKey, or (5) platformDD1 parameter to frameworkgui/attach2Agents.p...

CVE-2012-5695
Published: 2014-10-20
Multiple cross-site request forgery (CSRF) vulnerabilities in Bulb Security Smartphone Pentest Framework (SPF) 0.1.2 through 0.1.4 allow remote attackers to hijack the authentication of administrators for requests that conduct (1) shell metacharacter or (2) SQL injection attacks or (3) send an SMS m...

CVE-2012-5696
Published: 2014-10-20
Bulb Security Smartphone Pentest Framework (SPF) before 0.1.3 does not properly restrict access to frameworkgui/config, which allows remote attackers to obtain the plaintext database password via a direct request.

Best of the Web
Dark Reading Radio
Archived Dark Reading Radio
Follow Dark Reading editors into the field as they talk with noted experts from the security world.