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.

Risk

3/16/2010
09:33 AM
50%
50%

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
Comments
Newest First  |  Oldest First  |  Threaded View
Commentary
What the FedEx Logo Taught Me About Cybersecurity
Matt Shea, Head of Federal @ MixMode,  6/4/2021
Edge-DRsplash-10-edge-articles
A View From Inside a Deception
Sara Peters, Senior Editor at Dark Reading,  6/2/2021
Register for Dark Reading Newsletters
White Papers
Video
Cartoon
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
CVE-2021-34682
PUBLISHED: 2021-06-12
Receita Federal IRPF 2021 1.7 allows a man-in-the-middle attack against the update feature.
CVE-2021-31811
PUBLISHED: 2021-06-12
In Apache PDFBox, a carefully crafted PDF file can trigger an OutOfMemory-Exception while loading the file. This issue affects Apache PDFBox version 2.0.23 and prior 2.0.x versions.
CVE-2021-31812
PUBLISHED: 2021-06-12
In Apache PDFBox, a carefully crafted PDF file can trigger an infinite loop while loading the file. This issue affects Apache PDFBox version 2.0.23 and prior 2.0.x versions.
CVE-2021-32552
PUBLISHED: 2021-06-12
It was discovered that read_file() in apport/hookutils.py would follow symbolic links or open FIFOs. When this function is used by the openjdk-16 package apport hooks, it could expose private data to other local users.
CVE-2021-32553
PUBLISHED: 2021-06-12
It was discovered that read_file() in apport/hookutils.py would follow symbolic links or open FIFOs. When this function is used by the openjdk-17 package apport hooks, it could expose private data to other local users.