To get help with secure software development issues, find your own flaws

RSA Conference 2012 experts say finding and sharing real internal secure software development issues is the best motivator for change.

SAN FRANCISCO – When it comes to internal evangelism for secure software development, it helps to point to external examples of companies that have suffered from ignoring security, but highlighting internal software security problems is the best motivator for change.

That was one of the key messages espoused Thursday at RSA Conference 2012 by a panel of software security experts who represent several of the industry's biggest software vendors. Moderated by Brad Arkin, director of product security and privacy at Adobe Systems Inc., the panelists shared best practices for fostering secure software development.

The most powerful way to foster internal support for secure software development is to shine a spotlight on real or potential flaws and examine how the fallout would affect one's own organization, said Gunter Bitz, director of software quality assurance for German software giant SAP AG.

Bitz highlighted two examples from 2005 that helped spawn a greater emphasis on secure software development at SAP.

In one case, a close inspection of SAP software engineers' coding practices revealed that a developer had inserted a shortcut into the code that allowed him to debug his own code more quickly by skipping the security authentication capabilities built into the software.

"And the scary thing was: What happens if Joe Developer forgets to remove that before the product ships?” Bitz asked. “Basically you have a backdoor in the code."

Bitz said after finding that example, he took it to an SAP board meeting and explained the problem and the implications for the company and its customers if such an issue had ever gone undetected.

"It would send out the message that our company is not able to control our own software development lifecycle. That's a pretty bad message to send out," Bitz said. "The response from the board was straightforward: Make sure things like that don't happen."

In another example, Bitz said an independent security researcher approached SAP with more than a half dozen security vulnerabilities he had found in the vendor's software, which all together would grant someone complete control over a system.

Instead of ignoring the problem, Bitz said SAP invited the researcher to present the issues to the software company's key stakeholders, and negotiated an agreement with the researcher to not reveal the flaws until they had been fixed. Those two instances together, he said, convinced executives to invest more in secure software development.

Steve Lipner, senior director of security engineering strategy within Microsoft's Trustworthy Computing Group, shared a similar experience. Back in 2001, when the Nimda virus was ravaging the Internet and a devastating Universal Plug-and-Play (UPnP) flaw had been discovered in Windows XP, his team had an off-site meeting to strategize ways to evangelize the need for improving secure software development at Microsoft.

Lipner said that's when the idea to halt Windows development for several months was first conceptualized. With several worst-case scenarios already playing out in the public domain, the team began what was essentially an internal marketing effort to change how the software giant built its products.

What made the difference, Lipner said, was pure persistence: Only after many meetings with numerous department heads and executives did the value proposition of secure software development work its way up the chain of command, eventually resulting in the fundamental changes brought about by Microsoft's Trustworthy Computing program.

Gary Phillips, senior director of research and development for security software vendor Symantec Corp., said his company's reasons for initially investing in secure software development some years ago could be boiled down into one word: fear.

Phillips said his malware response team began to see malware exploiting zero-day flaws in its software. While there was no one watershed moment, he said the combination of several such events over a short period of time made it clear that secure software development needed to be a dedicated practice within the organization.

Bitz said the best method for finding secure software development issues to foster support for change will vary from one organization to another. He said some organizations with strong development teams will likely be able to find their own flaws, but in other cases, it's necessary to hire external penetration testers to find weaknesses that can then be leveraged in internal discussions.

Even if it takes a while to find flaws, Bitz said, start with the organization's flagship software, because software security problems there will serve as the most powerful motivator for decision makers.

Attendee Bianca Lee, with the Navy Common Access Card Program Management Office (CAC PMO) at the Naval Air Station in Pensacola, Fla., agreed that looking for secure software issues internally can bring about change, but that shouldn't mean ignoring external examples either.

"Your own disaster isn't the only way," Lee said, adding that there are plenty of powerful external incidents happening all the time. "If I see my neighbor's roof is on fire, maybe I should invest in fire insurance."

View all of our RSA 2012 Conference coverage.

This Content Component encountered an error

Pro+

Features

Enjoy the benefits of Pro+ membership, learn more and join.

0 comments

Oldest 

Forgot Password?

No problem! Submit your e-mail address below. We'll send you an email containing your password.

Your password has been sent to:

-ADS BY GOOGLE

SearchCloudSecurity

SearchNetworking

SearchCIO

SearchConsumerization

SearchEnterpriseDesktop

SearchCloudComputing

ComputerWeekly

Close