Protecting Test-Data Privacy
Protecting Test-Data Privacy
Security and access procedures in place for production environments don't always translate to test environments. But the same government regulations and industry requirements still apply.
By Suzanne Schroeder March/2009
Printer-Friendly Version
Email this Story
Bookmark to del.ico.us
Digg It!

Protecting Test-Data PrivacyLiving in the information age has become both a blessing and a curse. People have access to every kind of information from almost any location. As a result, it's easy to pay bills, access account information, and make purchases without leaving the comfort of the living room.

Unfortunately, all that information, which has to be collected, managed, and stored, has become a lucrative target for thieves. Ensuring that confidential data remains

protected and secure across the enterprise has become a critical business issue.

Yet news headlines about data privacy breaches have become almost as common as sports scores. Consider what happened at Certegy Check Services Inc., a subsidiary of Fidelity National Information Services Inc.: In 2007, a 2.3 million-record data breach at the company made headlines when a DBA stole banking and credit card information, then sold it to a broker. The broker subsequently sold some of the data to direct marketing organizations for solicitation. (See the article "Malicious insider sells Fidelity National customer data" for details.)

The Need for Privacy Protection

Data thieves have been known to acquire backup tapes, disk drives, user IDs, and passwords. Hackers take advantage of vulnerable network or infrastructure security or poor server or database security standards. A 2009 article in Baseline Magazine suggests that disgruntled employees experiencing layoffs and personal financial woes may be tempted to turn to IT crimes to mitigate their losses. Whatever the motivation of the perpetrator, data breaches continue to occur. According to the Privacy Rights Clearinghouse, as of February 2009, the total number of records containing sensitive personal information involved in security breaches in the U.S. since 2005 has surpassed 253 million.

But protecting information against thieves and hackers is only half the battle. As government regulations and industry requirements around the globe become more stringent, remaining compliant with privacy laws and industry regulations gets harder. Table 1 shows some of the data privacy laws and regulations enacted over the past ten years.

Table 1. Some industry regulations and standards in place today.

Noncompliance can result in myriad problems, including legal fees and monetary fines, jail time for executives, brand damage, and customer loss. In the midst of unprecedented numbers of security breaches, protecting privacy makes good business sense.

What Data to Protect

Typically, there are three main types of data that organizations must be careful to safeguard:

  • Customer data, including client names, addresses, account numbers, and payment card information
  • Employee data, including employee names, Social Security numbers, email addresses, and telephone numbers
  • Trade secrets, including financial data, cost of goods sold (inventory lists), and information about new product updates.

All this information is managed in various production databases and other company repositories. Most production environments have established security and access restrictions to protect against breaches. Standard security measures can be applied at the network level, application level, and database level. Organizations are even applying application development best practices as part of the daily process to ensure that application code is written to be more secure. However, these protective measures can't be replicated across every environment because the methods that protect data in production may not meet the unique requirements for protecting nonproduction (testing, development, and training) environments.

Where to Protect Data

The standard methods for protecting privacy in production environments may not be as effective when applied to data in nonproduction environments, in which developers, testers, and trainers require access to realistic data. A December 2007 report from the Ponemon Institute found that 62 percent of companies surveyed used actual customer data to test applications during the development process. The report, called "The Insecurity of Test Data: The Unseen Crisis," also found that 50 percent of respondents had no way of knowing whether the data used in testing had been compromised. Fifty-two percent of respondents outsourced application testing and 49 percent shared live data. Finally, 26 percent of respondents said they did not know who was responsible for securing test data.

Nonproduction environments can pose a tremendous threat to an organization and must be treated with the highest levels of security, with as much importance as a system in production. Standard nondisclosure agreements may not deter a disgruntled employee from taking a database full of actual Social Security numbers. An application developer's laptop containing a test database could be lost or stolen. Cloned databases sent to outsourcers for testing activities could be easily intercepted.

Let's examine a simple, hypothetical testing scenario. XYZ retailer wants to improve its online ordering system to improve customer service and increase customer retention. The application improvements require testing and development activities, so copies, or clones, of production data are used to create more realistic and accurate testing conditions. Because these clones are taken directly from the production environment, they contain personally identifiable information such as names, addresses, payment card numbers, so on. Once cloned, this information is then propagated from a secure production environment to a more vulnerable nonproduction environment.

So why not just test in the production environment and save time and resources? Application data needs to be tested outside the production environment so that errors that occur during testing won't affect the live production system. Sometimes multiple testing environments are required, putting multiple copies of production information at risk.

But test data need not contain personally identifiable information — it just needs to be realistic. Some companies believe that encrypted data will suffice. But encryption is not always adequate in nonproduction environments.

Next Page >>


Comments? Questions?

Give us your feedback or ask a question of the author.

Please enter your e-mail address below:

CAREER CENTER
Ready to take that job and shove it?
SEARCH JOBS
RECENT JOB POSTINGS
CAREER NEWS
DoD Recognizes University Scientists For Basic Research
Annual awards to university faculty to conduct next-generation research projects were announced this week by the Defense Department.

Sponsored links:





Visit these other IBM and TechWeb Partner Sites: :
Maximizing ROI Through Business Process Management (BPM) and Service-Oriented Architecture (SOA)
Internet Evolution – The Macrosite for News, Analysis, & Opinion About the Future of the Internet
Business Innovation – Technology Strategies and Solutions for Driving Business Success