Dark Reading is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them.Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.


09:33 AM

Live Data In Test Environments Is Alive And Well -- And Dangerous

Nearly 85 percent of financial firms use production data while developing and testing applications, so DBAs and database security need to better coordinate with developers

Those charged with the care and feeding of database information stores, beware: A new statistic tucked into a comprehensive study of financial services firms' data protection policies shows that even at the most security-aware organizations, application developers still use live data in their development and test environments.

The study, released earlier this month by the Ponemon Institute and commissioned by Compuware, showed that among 80 very large financial organizations, 83 percent use live data while developing and testing applications. That's a big risk to sensitive information, data security experts warn, and is a testament to the fact that DBAs and database security experts need to step up their efforts to work in tandem with their development colleagues to protect the data that these coders get their applications to tap into.

"Most organizations are still using live data in test and development environments because of a lack of awareness around data security, and they don't know they can easily mask or de-identify sensitive data using off-the-shelf technologies without changing applications or testing processes," says Phil Neray, vice president of security strategy at Guardium, an IBM company.

Even when the awareness is there, organizations still tend to rely on real data for its speed and ease of use, says Brian Contos, chief security strategist for Imperva.

"Using live, cloned data is generally regarded as a shortcut when there isn't enough time or resources to create test data, or a secure test data strategy isn't in place," he says.

But these are not excuses for a practice that can put customer data in great jeopardy. "It is true that in general these test systems are not Internet-accessible, but even if you have absolute trust in all your employees -- never a good starting point -- that doesn't remove the risk, as many organizations will outsource parts of development and hire contractors, consultants, and the like," Contos says. "And if the media has taught us anything over the last decade about carelessness, it's that people often store this type of data on laptops and removable media devices, and those assets can get lost or stolen."

Beyond the insider threat, there's also the very real possibility that malicious external hackers can eventually work their way deep enough into the network after a blended attack and get their hands on test applications and live data. Adam Muntner, managing partner of security consultancy QuietMove, regularly conducts penetration tests for his clients. Munter says the use of production data from the database is an all-too-common weakness he finds when he's looking to poke holes in his client organizations' security.

"Use of production data can accelerate testing, but needs to be done with extreme caution," Muntner says. "During many a penetration test, we've hacked our way to the keys of the kingdom through test systems that were not maintained up to the standards of production systems, yet contained the same data."

Part of the difficulty with this issue is that preventative measures require the cooperation of both the database stakeholders and the application developers.

"Generally, developers ought to obfuscate and anonymize any data in a test system which could be considered personally identifiable information. This would include email addresses, phone numbers, IP addresses, mailing address, etc.," Muntner says. "If an organization's operations team could obscure this data before delivering it, the chance for exposure shrinks even more."

One of the first steps is to formalize a process within the organization requiring authorization from the data and application owners for production data -- keeping everyone in the loop and preventing mistakes by untrained junior members of the team. And at the very least, Muntner says, personally identifiable information, such as social security numbers, e-mail addresses, phone numbers, IP addresses, mailing addresses, and so on should be anonymized, preferably where the data resides. If possible, the DBA can be brought in to leverage SQL commands, such as RAND, REPLICATE, and REPLACE, he says.

An even safer option is the use of artificial data generation using regular expressions and predefined ranges of values to generate realistic but fake test data, Munter says. He suggests two open-source tools, dbMonster and Generate Data, to help with the task.

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

Comment  | 
Print  | 
More Insights
Newest First  |  Oldest First  |  Threaded View
NSA Appoints Rob Joyce as Cyber Director
Dark Reading Staff 1/15/2021
Vulnerability Management Has a Data Problem
Tal Morgenstern, Co-Founder & Chief Product Officer, Vulcan Cyber,  1/14/2021
Register for Dark Reading Newsletters
White Papers
Cartoon Contest
Write a Caption, Win an Amazon Gift Card! Click Here
Latest Comment: This is not what I meant by "I would like to share some desk space"
Current Issue
2020: The Year in Security
Download this Tech Digest for a look at the biggest security stories that - so far - have shaped a very strange and stressful year.
Flash Poll
Assessing Cybersecurity Risk in Today's Enterprises
Assessing Cybersecurity Risk in Today's Enterprises
COVID-19 has created a new IT paradigm in the enterprise -- and a new level of cybersecurity risk. This report offers a look at how enterprises are assessing and managing cyber-risk under the new normal.
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
PUBLISHED: 2021-01-20
OpenMage is a community-driven alternative to Magento CE. In OpenMage before versions 19.4.10 and 20.0.6, there is a vulnerability which enables remote code execution. In affected versions an administrator with permission to update product data to be able to store an executable file on the server ...
PUBLISHED: 2021-01-20
Weave Net is open source software which creates a virtual network that connects Docker containers across multiple hosts and enables their automatic discovery. Weave Net before version 2.8.0 has a vulnerability in which can allow an attacker to take over any host in the cluster. Weave Net is suppli...
PUBLISHED: 2021-01-20
A vulnerability in the CLI of Cisco SD-WAN vManage Software could allow an authenticated, local attacker to read sensitive database files on an affected system. The vulnerability is due to insufficient user authorization. An attacker could exploit this vulnerability by accessing the vshell of an af...
PUBLISHED: 2021-01-20
Multiple vulnerabilities in Cisco SD-WAN products could allow an unauthenticated, remote attacker to execute denial of service (DoS) attacks against an affected device. For more information about these vulnerabilities, see the Details section of this advisory.
PUBLISHED: 2021-01-20
Multiple vulnerabilities in certain REST API endpoints of Cisco Data Center Network Manager (DCNM) could allow an authenticated, remote attacker to execute arbitrary SQL commands on an affected device. For more information about these vulnerabilities, see the Details section of this advisory.