​

When a car manufacturer rushes a new model to market and then finds a problem, the resulting recall is likely to cost more than preventing the problem in the first place.

Software vendors aren’t required to recall their products if security holes are found; rather, they send out patches and updates, each a reminder that the original work wasn’t done properly. But why is it so hard to write secure code in the first place?

“Software developers develop ‘functional spec,’” says Kenneth R. van Wyk, coauthor of the book Secure Coding: Principles and Practices and principal consultant of KRvW Associates, an information-security consulting firm. “They’re told to write a piece of software that does this and that, but they’re not really good at considering security ramifications,” such as imagining how someone could deliberately and maliciously misuse the application.

Ralph Massaro, general manager, content products, of LogicLibrary, Inc., adds that marketing has traditionally trumped security. Developers are focused on features and functions and getting the product to market quickly, he says, and “there tends not to be much focus on how to code securely.”

Marc Shinbrood, CEO of Breach Security, explains that the problems are not simply a result of poor coding but also of what programmers do to test the functionality of, or provide backdoors to, the applications while they are developing them, such as using a string of X’s in the password field.

“They expect that nobody’s going to do that when the application gets to the real world,” he says, but if someone discovers the option, they now have a backdoor into the system.

For example, Shinbrood says that he worked with an Israeli airline company to look for security holes in a Web application. In a field for passport numbers, he discovered that programmers had tested the application by entering all 9’s, assuming that no real passport would have that format. Discovering that hole gave him access.

LogicLibrary is helping software developers find problems during coding, Massaro says. After writing code, the developer uses a Web interface to submit the code to Logicscan 2.0, the company’s automated analyzer.

Logicscan looks for known security issues, such as buffer overflows, tells the developer exactly what the security problems are, and provides remediation advice so that necessary changes can easily be made, says Massaro.

While these types of tools can help fix common mistakes, they leave correction up to the developer, says Ted Julian, vice president of marketing for AppSecInc. “In the case of reviewing source code, more often than not, I suspect it’s a judgment call,” he says, “because it depends on how that function is used within the context of the broader application. Whether or not what appears to be an issue is an issue at all, or how severe an issue is, is not an easy thing to automate.”

Companies can mitigate their risk by using application firewalls, which are designed specifically to prevent applications from being maliciously misused. Shinbrood says that new generations of application firewalls are looking at behavioral elements so that even new attacks can be recognized by the software and so that outsiders and insiders are prevented from misusing an application.

Despite the need for these end-user tools, van Wyk says that the problem needs to be addressed at its root. “Protecting against somebody doing a buffer overrun in a shopping cart application should’ve been done when the application was written,” he says.