Dark Reading is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them.Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

Risk

4/25/2013
01:46 AM
Connect Directly
Twitter
RSS
E-Mail
50%
50%

How To Stop Making Excuses For Poor Application Security Testing

Policies, prioritization, and planning can keep obstacles from standing in the way of solid preproduction security testing practices

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 Ericka Chickowski specializes in coverage of information technology and business innovation. She has focused on information security for the better part of a decade and regularly writes about the security industry as a contributor to Dark Reading.  View Full Bio

Comment  | 
Print  | 
More Insights
Comments
Oldest First  |  Newest First  |  Threaded View
marktroester
50%
50%
marktroester,
User Rank: Apprentice
4/26/2013 | 2:51:18 AM
re: How To Stop Making Excuses For Poor Application Security Testing
Hello Ericka - Thanks for the interesting and informative article. I especially like the comments on policy. What we have seen is that organizations fail when they implement policies that are not designed to support agile, component-based development efforts. Policies that allow experimentation early in the development process and notification to the developer that the component is not approved are necessary to meet the short development cycles. As the application progresses through the development lifecycle, if the component is not approved, the policy can then stop the application from being migrated to production. We also see organizations that provide information early in the development lifecycle, and organizations that integrate security guidance throughout the development lifecycle achieve success.

Mark Troester

Sonatype

@mtroester
Register for Dark Reading Newsletters
White Papers
Video
Cartoon Contest
Current Issue
6 Emerging Cyber Threats That Enterprises Face in 2020
This Tech Digest gives an in-depth look at six emerging cyber threats that enterprises could face in 2020. Download your copy today!
Flash Poll
State of Cybersecurity Incident Response
State of Cybersecurity Incident Response
Data breaches and regulations have forced organizations to pay closer attention to the security incident response function. However, security leaders may be overestimating their ability to detect and respond to security incidents. Read this report to find out more.
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2020-11619
PUBLISHED: 2020-04-07
FasterXML jackson-databind 2.x before 2.9.10.4 mishandles the interaction between serialization gadgets and typing, related to org.springframework.aop.config.MethodLocatingFactoryBean (aka spring-aop).
CVE-2020-11620
PUBLISHED: 2020-04-07
FasterXML jackson-databind 2.x before 2.9.10.4 mishandles the interaction between serialization gadgets and typing, related to org.apache.commons.jelly.impl.Embedded (aka commons-jelly).
CVE-2020-11509
PUBLISHED: 2020-04-07
An XSS vulnerability in the WP Lead Plus X plugin through 0.98 for WordPress allows remote attackers to upload page templates containing arbitrary JavaScript via the c37_wpl_import_template admin-post action (which will execute in an administrator's browser if the template is used to create a page).
CVE-2020-6647
PUBLISHED: 2020-04-07
An improper neutralization of input vulnerability in the dashboard of FortiADC may allow an authenticated attacker to perform a cross site scripting attack (XSS) via the name parameter.
CVE-2020-9286
PUBLISHED: 2020-04-07
An improper authorization vulnerability in FortiADC may allow a remote authenticated user with low privileges to perform certain actions such as rebooting the system.