eWEEK content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More.
Sometimes it doesn’t take an external hacker to reveal customer data. Often, it happens during the application development process itself.
That is because, according to a recent survey from the Ponemon Institute, many organizations use production data during their development and testing process without having proper safeguards in place. Some of this, experts say, is due to enterprises underestimating the possibility of an insider threat; other times, it’s simply companies going with what’s easiest.
“Organizations use real customer data because it is easy for developers to just make a copy of a production database that they can use for testing. It takes a lot more effort to encrypt private data or create a phony test database,” said Forrester Research analyst Mike Gualtieri.
His point was underscored by the Ponemon survey (PDF), which focused on application developers and testers in the United States and the U.K. In the survey, 71 percent of the 701 U.S.respondents said that when it comes to the development and testing process, they either don’t have adequate policies for protecting data or are unsure – a serious problem, since 80 percent are using real data.
Oftentimes, enterprises simply do not consider insider breaches as likely as they do external hacks, and therefore there is less concern, noted Gartner analyst Joseph Feiman.
“If an insider, an employee, attacks the enterprise, this is [the] most well-kept secret,” he said. “Enterprises don’t want to lose their reputation. So there is a lack of awareness of insider attacks.”
Developers do have some valid reasons for using real data during the jobs. After all, it does save time and complexity, analysts said.
“As system complexity and interdependencies increase it becomes harder and harder for development teams to create realistic and representative test data,” explained David West, an analyst with Forrester. “This difficulty is only increased by the need to deliver more functionality faster and with less people. The third dimension is the lack of knowledge people have of legacy systems and their data. Over time data structures have evolved to such an extent that original labels and definitions are wrong, or at least wrong some of the time.”
“The result is development teams look to the only source of true data, that of production,” he said.
Still, through technologies such as data masking, enterprises could reduce the threat. Though data masking adoption has grown over the last five years however, the technology remains largely unused by the majority of organizations, analysts said, due to problems deciding what to mask as well as the volume of data. More than two-thirds of the U.S. respondents told the Ponemon Institute they do not mask data before it is used in testing.
Still, Gualtieri contends there is no excuse for organizations to not encrypt or mask data during the development process.
“I recently saw an online travel booking company had unencrypted credit numbers for hundreds of hotel customers,” he said. “I told the CEOthat he had to address this right away. The biggest difficulty that app dev shops face in encrypting data is to provide a consistent way to encrypt/decrypt the data and manage keys. The best way to do this is to not have developers do it all. It should be automated either in the database or in the data access layer. For example, if they code it Java you can use the Spring framework to inject encryption for named fields automatically. That way developers don’t have to remember.”