• United States



Layered defense for software applications

Apr 09, 20129 mins
Application SecurityData and Information SecurityManufacturing Industry

Securing your applications has never been more important, and there are lots of ways to do just that -- as long as you don't mind onions

What do application security programs and onions have in common? Layers, says Ken Pfeil, global security officer at Pioneer Asset Management.

Securing corporate applications is a top priority for most security executives. Application vulnerability was the most feared threat for 73 percent of respondents to a 2011 study by (ISC)2, topping mobile devices, viruses and worms, and internal employees.

[Also read Vulnerability management basics]

But while some companies might try to secure applications by investing in a tool--such as penetration testing or Web application firewalls--a robust application security program should take a multi-layered approach that addresses the operating system, the network layer and the development of the code itself.

Pfeil, for instance, aims his application security efforts at a variety of targets, from business executives to developers. His program includes developing business-risk-analysis reports, scheduling training sessions with development leads to gain their buy-in (and hopefully turn them into security advocates), and running a “How to Hack Web Apps” class twice a year.

These classes, he says, encourage developers to build security techniques into their code from the start, such as by applying Microsoft’s Managed Code Security Guidelines and criteria from the Web Application Security Consortium. Ultimately, Pfeil says, his team uses 47 application security checks, from basics such as cross-site scripting to less-obvious measures that he says are proprietary and can’t be shared.

No Silver Bullet

Such a nuanced approach is necessary to address today’s continuously changing threat landscape and complex application environments, including mobile apps, Web 2.0, custom code, commercial software, and departmental and outsourced applications.

With every code update, a new risk can be created, and even interactions between applications can cause unanticipated security problems. This complexity explains why there is no silver bullet for application security; instead, it requires a disciplined effort that involves time, money and people.

Relying on tools alone--such as penetration tests that simulate attacks on networks and applications--is a bit like playing whack-a-mole, according to Andy Ellis, CSO at Akamai Technologies. “They only show you how bad your code is,” he says. Finding the problem doesn’t solve the problem, and pen tests also don’t reveal all your code gaps. At Akamai, for instance, after a defect was revealed through pen testing, “we had a security researcher look in the [code] library, and lo and behold, we had 20 other defects,” Ellis says.

Jennifer Bayuk, a security consultant and program director of the Systems Security Engineering program at the Stevens Institute of Technology, is similarly skeptical of “bolt-ons” that sit on the application and check how secure it is, such as Web application firewalls. “You use a Web application firewall because your code is buggy and you know it,” she says.

Due for a Change

The Ponemon Institute’s 2011 “State of Web Application Security Survey” suggests companies barely have a handle on their applications, never mind on their application security. A quarter of respondents could not estimate the number of applications their firm had, and a fifth did not test application security at all. At those firms that did test, 40 percent tested only 5 percent of their applications, and two-thirds tested less than 25 percent of their applications.

In addition, the (ISC)2 study found that expenditure on application vulnerability management was just under 11 percent of network infrastructure spend. And despite the concern about application security, that number is actually projected to fall to about 10 percent by 2015.

Rob Ayoub, author of the (ISC)2 report and now a sales engineering manager at Fortinet, notes that over the last five years, three major changes have occurred in security vulnerabilities:

  • Operating system vulnerabilities dropped while application vulnerabilities rose;
  • Apple products and specialized systems became bigger targets;
  • and remote exploitation of critical vulnerabilities increased.

Despite these changes, “many organizations continue to address security the same way they have for years,” writes Ayoub, who was program manager at Frost and Sullivan at the time of the study. “It is imperative for CXOs to balance their existing budgets and security postures with the latest trends.”

Getting to the Code

While CSOs can certainly make smart product purchases to improve application security, it would be better to spend more effort on developing better software and testing.

An example is setting standards for naming function commands, says Bayuk. She suggests that companies start with coding standards that include security and then ensure that the quality-assurance cycle includes functional security testing and abuse cases. When developers follow similar naming conventions for program commands and data field standards, it becomes easier to automate methods of finding code vulnerabilities, Bayuk says.

Companies should also consider building code inventories, she says, so they know which code corresponds to which business process.

The rise of the Web has made coding standards more important, in part because browsers are more forgiving of code errors, Bayuk says. If each developer can independently determine, for instance, what a backslash represents, it could result in a code base in which a single command takes on multiple meanings. If a vulnerability is due to one use of such a command, it will be difficult to tell which instance of that command is at fault.

Companies may be more secure if they write their own applications, assuming they have the resources to do so, Bayuk says. At Bear Stearns, where she was CISO until 2008, one group wrote its own Web server. “[It] never had a finding in our penetration studies,” she says, and it was faster than off-the-shelf offerings. That sort of specialized application will, as a rule, be harder to hack than commercial software. But writing your own specialized applications will also require more expertise and time than buying off-the-shelf products.

The Time Trade-Off

Adding security to the beginning of the application development processes, of course, will often slow down code development. As a result, CSOs may face push-back if they do their jobs, which makes it harder to increase vulnerability testing during development, Pfeil says.

Projects have fixed costs and delivery dates, which can make business units reluctant to spend a few extra days testing for vulnerabilities. Many software teams build code first and then “retroactively ask security if they have a problem with it,” Pfeil says. Few companies set up a framework that builds security controls into their software development lifecycle, he says.

Such push-back is the reason Pfeil and other forward-thinking CSOs do the extra politicking required to ensure buy-in from other executives. “As business security people, the problem is, we impact time to market and cost of goods sold,” says Roland Cloutier, vice president and CSO at ADP. As a result, he says, CSOs have to build the case that it’s worth it to build security testing into every step of the development process, because ultimately it will mean better code at the end, with less complexity and less re-engineering costs.

Cloutier also advocates taking a multi-layered approach. “It’s time to start looking at the whole delivery architecture,” he says, from the back-end inventory database to the front end where a payment method is specified. “We have to test the application’s relationship with the rest of the system.”

Of course, for large organizations with thousands of developers working on hundreds of products, looking at the entire application environment is no small effort. One practice that can make it easier is to integrate a scanning tool into the developer’s toolset. “Give them an option that says, ‘I would like my code scanned tonight.’ Then when they come in in the morning, their code is tested.” Similar options are included in any number of toolkits from big and small vendors, including IBM, Hewlett-Packard, Veracode and Qualys. “They all have great toolsets that integrate into developer environments,” says Cloutier.

Communication Is Key

Even more complexity is added when business departments hire or outsource development without IT involvement. In those cases, CSOs need to ensure that all developers understand basic security concepts such as encrypting credit card and personal information.

This is often a matter of developing relationships with executives in all business departments to keep tabs on what’s being developed, says Parag Patel, CTO at AutoAnything. At the online automotive retailer, C-level execs regularly discuss new projects to ensure that, for instance, if marketing hires a firm to build a mobile website, Patel is aware of it and can ensure that the effort complies with security and management policies.

In many ways, organizational understanding and awareness of application security is maturing, especially as application portfolios grow more complex, thanks to mobile apps and the Web. Akamai CTO Ellis notes that it’s a relatively new concern to build security into the application. SSL and SSH, he notes, did not exist when the Web was first created. As applications have become more complex and encrypted protocols have spread, “we do a lot more work to defend the application,” he says.

More on application security: