Bringing Security into the Development Process

By Brian Prince  |  Posted 2007-10-11 Print this article Print

Vendors and analysts warn that the open culture of application development can lead to security vulnerabilities and data leaks.

When it comes to data leaks, most of the talk is about hackers breaking into networks or employees e-mailing and downloading sensitive information. But some vendors are paying more attention to the preproduction environment, where there are often security holes big enough to push a hard drive through.

"The development environment and quality assurance environment have always been...significantly more open and free," said Louis Carpenito, former vice president of information security business strategy at Symantec.

Carpenito, now an independent consultant, said the environments often lack security measures such as access control and event management. Despite not having these safeguards, many organizations still use real customer data in their development and quality assurance environments, he said.

"The risks that have been prevalent throughout the years have been mostly risks of Trojans being implanted, allowing individuals to come in and steal information or commit fraud," Carpenito said. "Therefore I think the risk of the information in development environments, in QA environments, really is much more significant, because in production environments, one usually detects at some point in time-obviously after its too late-that data has leaked out of the environment. The likelihood of that being identified in a development, QA environment is highly unlikely."

With this in mind, vendors such as Gamma Enterprise Technologies and Fortify Software are looking to improve security in the development phase.


Gamma, based in Woodland Hills, Calif., offers a data obfuscation tool called InfoShuttle Data Security, to protect data in SAP development and test environments. The tool accesses the InfoShuttle Content Library, a repository of SAP objects and relationships, to automatically detect all related fields deep in SAPs data structures for identifying and masking confidential data.

In addition, it disguises data according to different rules, such as shuffling existing key fields and replacing data with unique generated numbers while maintaining consistency across multiple data tables, Gamma officials said.

"The development environment by its very nature is an open one with access granted to a wide range of in-house staff and often to outside contractors," said Suzanne Swanson, executive vice president of Gamma. "Having open systems need not mean having open data."

The issue of in-house development systems being security problems is valid, said Gartner analyst John Pescatore. Developers leave things wide open to make it easier to debug applications and work remotely, he said, and often use group accounts or accounts with no password.

"Enterprises really have to segment them off from the main network as a minimum, and make sure only strongly authenticated remote access is supported. Developers trying to open up remote access is a huge issue," he said. "The test data issue is another major problem. There are data masking solutions out there...I recommend that actual customer data not be used."

Security researchers at Fortify Software reported in their Oct. 9 white paper, "Attacking the Build through Cross-Build Injection," a class of security vulnerabilities they are calling cross-build injection. These vulnerabilities, which Fortify discovered through its work with the JOR (Java Open Review) project, allow a hacker to insert code into the target program while it is being constructed.

Click here to read more about the cost of data leaks.

The researchers found that during the application build process, systems that automatically download external dependencies-such as build tools Ant, Maven and Ivy-are particularly vulnerable. While external dependencies and open-source components do not necessarily represent an unacceptable security risk, Fortifys researchers demonstrate that they deserve proper vetting to ensure they do not compromise the security of applications that make use of them.

Though automated and repeatable systems for compiling code are used to simplify the software development process, they have also opened the doors to possible system-wide exploits, the researchers report. Fortify can guard against this with its Fortify SCA tool, which can detect the potential for cross-build injections by analyzing build files while it analyzes source code, said officials at Fortify, based in Palo Alto, Calif.

"When software that depends on external components is built, an attacker may either target the server that hosts the open-source component or the DNS server that the build system uses to resolve the name of the remote server," Jacob West, security research group manager at Fortify, said in an interview with eWEEK.

But the problems are not unique to open source, he said.

"Cross-build injection can impact any component that is retrieved from an external repository," he said. "Typically, this most often impacts software that relies on open-source components, but other third-party or internally developed components hosted externally are equally susceptible."

Check out eWEEK.coms Security Center for the latest security news, reviews and analysis. And for insights on security coverage around the Web, take a look at eWEEKs Security Watch blog.


Submit a Comment

Loading Comments...
Manage your Newsletters: Login   Register My Newsletters

Rocket Fuel