Pressure mounts for building in security during application development

Microsoft survey of IT pros and developers worldwide found only 37% worked for organizations that built products with security in mind

Security has seldom been a priority in application development, but pressure from businesses stuck patching faulty software is having an impact on the industry.

Among the large software makers that have seen the light is Microsoft, which is pushing Windows developers to adopt a standard methodology and framework for building secure applications.

In April, Oracle got religion with Java, which is notorious for vulnerabilities, and said it would delay the next major upgrade, so engineers could work on plugging holes

Prioritizing security during the development process leads to fewer holes that hackers can exploit, experts agreed Friday. Higher quality software also means fewer patches, which reduces maintenance costs for vendors and customers.

"We need more secured software, not more security software, " said Jeremiah Grossman, chief technology officer for the website security company WhiteHat Security.

Nevertheless, software makers have chosen to avoid the additional cost in time and resources for initially securing their products. They have gotten away with this because security has not been on customers' checklists when shopping for software.

That's changing. Matthew Neely, director of research and development for consulting firm SecureState, said large businesses are demanding more secure software from major vendors, which are starting to change their development practices. Over the next few years, he expects customer demand to head downstream to mid-size vendors.

Smaller software makers will likely lag behind until better tools are available to automate the process of using best practices for application security, Neely said. "Getting it past the medium to the small companies is going to be hard, because of the resources required to put people in to do the security testing and to train the people."

[Also see: Microsoft commits to secure coding standard]

Microsoft shifted to prioritizing security in 2004 after years of battling cybercriminals who discovered that the ubiquitous Windows was an easy target.

"We heard our customers loud and clear at that time that our software needed to have fewer vulnerabilities and vulnerabilities that are in the software have to have lower severity," said Tim Rains, director of Trustworthy Computing for Microsoft.

Microsoft launched the Security Development Lifecycle (SDL) process, which today supports ISO/IEC 27034-1, a standard methodology published in 2011 by the International Standards Organization.

Microsoft's SDL is used by Adobe and Cisco and the company is actively marketing the free framework among developers, knowing that better security in third-party applications means a better user experience on Windows.

A benefit of using SDL or other framework supporting the ISO standard is in meeting regulatory requirements, Rains said. The security features built into the software overlaps with some of the federal requirements for securing healthcare records, and mandates for securing data related to credit-card transactions.

Despite the progress, the software industry remains weak in security. Universities that train coders lag in teaching best security practices and companies are not yet willing to provide the training themselves.

Microsoft recently sponsored a survey of more than 2,700 IT professionals and developers worldwide and found only 37% worked for organizations that built products with security in mind. The problem exists in on-premise and cloud-based software, experts say. 

"The time is right now to reprioritize secure development within these organizations and have that bubble up to the top of the list of priorities," Rains said. "If we don't take the time to do this right now, we're going to continue to see the types of successful attacks that we've been seeing more and more of."

Recommended
Join the discussion
Be the first to comment on this article. Our Commenting Policies