A survey by the Ponemon Institute underscores that many application testers and developers are using real production data without proper safeguards. Experts say it's time for a change.Sometimes it doesnt 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, its simply companies going with whats 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 dont 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 dont have to remember.
Network Security & Hardware 
