How To Stop Making Excuses For Poor Application Security Testing

Just as the old carpenter axiom warns to measure twice and cut once, the effort of putting in effective security testing practices earlier in the application development process saves many more headaches later in the application life cycle.

"We want to have applications that don't get surprise 'no's' in preproduction approval, and that don't get out there in production with more vulnerabilities," says Diana Kelley, application security strategist for IBM, who says that in her opinion it takes a "fundamental shift" in practices and mentality for enterprises to get there.

But to initiate that shift, organizations must stop making excuses and start addressing some of the obstacles that stand in the way of improved preproduction practices. First among them is a cultural "awareness obstacle," says Mike Armistead, vice president and general manager of HP Fortify.

"Security organizations for so long have been a bit reluctant to address the software side because the software side is usually a powerful part of the organization since they are putting new features in for the business," says Armistead. In spite of improved techniques and testing technology available, most organizations don't use them without some kind of external prod, like a failed audit or a data breach caused by software vulnerabilities, he notes.

[Think insiders can't hurt your firm? Think again. See 8 Egregious Examples Of Insider Threats.]

It may be less an awareness issue and more a matter of prioritization, though. According to Jeremiah Grossman, CTO and founder of WhiteHat Security, development managers are consistently faced with an impossible choice to make.

"Development managers are often faced with a decision as to whether they should assign a programmer to continue creating a feature that must ship by a certain date, because, if not, a slip will cost the business money," he says, "[or] fix a serious vulnerability that may get exploited and may cost the company money."

Not only must these development managers make this decision every day, they have to do it with incomplete information, he says.

"The development manger doesn't always know how much money is on the line with a particular feature, nor the likelihood of a successful exploitation and monetary loss," Grossman says.

The IT organization could take some of the pressure off of these folks' shoulders through better policy development. Armistead believes that clearly developed policies and standards take a lot of the guesswork out of the decision tree. They essentially provide guidance for where upper-level management priorities lie.

"Organizations that are the most successful in their software security initiative put policies in place -- and they can be as simple as 'anything that does not meet a certain level of criteria cannot get into the data center or be deployed,'" he says. "When the teeth have been put into a policy, the organization actually follows. If it stops them from shipping something, the software producers are generally really attuned to that."

But policies alone won't solve the problem. The policies have to be backed by resources. On the technology side, this means helping developers automate as much of the process as possible, without engaging in the game of throwing something "over the wall and saying 'all yours,'" Grossman says. Many of today's testing tools are extremely powerful -- sometimes so powerful that they can be overwhelming, a trait that could discourage regular use. So it might make sense for a tool that can test over 270 different things to start with only a couple factors.

"Most successful people are the ones that kind of understand that there is a balance there, and you should not just think of it as a big bug finder," Armistead says. "Because security is a little different in that way, right? It's ... about the risk, you know, the attack surface and the risk of where the application is. You need that human element to make those assessments."

Because every aspect of application security requires some amount of human input, even with the best technology available organizations will have to be prepared to invest in highly expert man hours to get testing done right. It's a challenge given the current talent shortage within the community of applications security experts. Given that, odds are high that organizations will have to plan for some sort of outsourcing to test regularly and effectively, Grossman says.

"These people must have very specific skills, and, as a result, they are highly sought after and their unemployment rate is effectively 0 percent," he says. "Organizations with a software security problem will then be forced to outsource, not because they want to but because they have to."

Most importantly, says Kelley, is organizations recognize that fundamental shifts don't happen suddenly. Success in getting testing practices to stick requires patience and dogged persistence -- and an understanding that there will be a learning curve.

"It's going to look like we've got a lot of steps that we have to add into this very squeezed, very agile, very time-driven process," she says. "It may take a lot longer [to develop that way], but you know what? Almost everything we do takes a long time when we start. If we say it's going to be too hard, we're never going to learn and get better. In organizations that keep doing it, it becomes part of the culture. They get better."

Have a comment on this story? Please click "Add Your Comment" below. If you'd like to contact Dark Reading's editors directly, send us a message