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
Cyberattacks Are Tailored to Employees ... Why Isn't Security Training?
Tim Sadler, CEO and co-founder of Tessian,  6/17/2021
7 Powerful Cybersecurity Skills the Energy Sector Needs Most
Pam Baker, Contributing Writer,  6/22/2021
Microsoft Disrupts Large-Scale BEC Campaign Across Web Services
Kelly Sheridan, Staff Editor, Dark Reading,  6/15/2021
Register for Dark Reading Newsletters
White Papers
Current Issue
The State of Cybersecurity Incident Response
In this report learn how enterprises are building their incident response teams and processes, how they research potential compromises, how they respond to new breaches, and what tools and processes they use to remediate problems and improve their cyber defenses for the future.
Flash Poll
How Enterprises are Developing Secure Applications
How Enterprises are Developing Secure Applications
Recent breaches of third-party apps are driving many organizations to think harder about the security of their off-the-shelf software as they continue to move left in secure software development practices.
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
PUBLISHED: 2021-06-24
Cross Site Scripting (XSS) vulnerability in gnuboard5 <=v5.3.2.8 via the url parameter to bbs/login.php.
PUBLISHED: 2021-06-24
CRMEB 3.1.0+ is vulnerable to File Upload Getshell via /crmeb/crmeb/services/UploadService.php.
PUBLISHED: 2021-06-24
In CRMEB 3.1.0+ strict domain name filtering leads to SSRF(Server-Side Request Forgery). The vulnerable code is in file /crmeb/app/admin/controller/store/CopyTaobao.php.
PUBLISHED: 2021-06-24
All versions of package react-bootstrap-table are vulnerable to Cross-site Scripting (XSS) via the dataFormat parameter. The problem is triggered when an invalid React element is returned, leading to dangerouslySetInnerHTML being used, which does not sanitize the output.
PUBLISHED: 2021-06-24
An issue was discovered in JFinal framework v4.9.10 and below. The "set" method of the "Controller" class of jfinal framework is not strictly filtered, which will lead to XSS vulnerabilities in some cases.