SAN FRANCISCO â€" On the subject of internal evangelism for secure software development, it helps to indicate to external examples of businesses which have suffered from ignoring security, but highlighting internal software security problems is the most effective motivator for change.
That was one of many 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 strongest approach to foster internal support for secure software development is to polish a focus on real or potential flaws and look at 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 better emphasis on secure software development at SAP.
In one case, a detailed 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 safety authentication capabilities built into the software.
"And the dreaded thing was: What happens if Joe Developer forgets to take away that before the product ships?†Bitz asked. “Basically you've a backdoor within the code."
Bitz said after finding that example, he took it to an SAP board meeting and explained the matter and the results for the corporate and its customers if such a topic had ever gone undetected.
"It will send out the message that our company is just not ready to control our own software development lifecycle. That's a lovely bad message to send out," Bitz said. "The response from the board was straightforward: Make sure that such things as that do not happen."
In another example, Bitz said an independent security researcher approached SAP with greater than a half dozen security vulnerabilities he had present in the vendor's software, which all together would grant someone complete control over a system.
Instead of ignoring the issue, Bitz said SAP invited the researcher to provide the failings to the software company's key stakeholders, and negotiated an agreement with the researcher not to reveal the failings until that they had been fixed. Those two instances together, he said, convinced executives to take a position more in secure software development.
Steve Lipner, senior director of security engineering strategy within Microsoft's Trustworthy Computing Group, shared an identical experience. Back in 2001, when the Nimda virus was ravaging the web and a devastating Universal Plug-and-Play (UPnP) flaw were discovered in Windows XP, his team had an off-site meeting to strategize easy methods to evangelize the will for bettering secure software development at Microsoft.
Lipner said that's when the assumption to halt Windows development for several months was first conceptualized. With several worst-case scenarios already playing out within the public domain, the team began what was essentially an internal marketing effort to switch how the software giant built its products.
What made the variation, Lipner said, was pure persistence: Only after many meetings with numerous department heads and managers did the worth proposition of secure software development work its way up the chain of command, eventually leading to the elemental changes triggered by Microsoft's Trustworthy Computing program.
Gary Phillips, senior director of analysis and development for security software vendor Symantec Corp., said his company's reasons for initially investing in secure software development some years ago may be boiled down into one word: fear.
Phillips said his malware response team started to see malware exploiting zero-day flaws in its software. While there has been no person watershed moment, he said the mixture of several such events over a brief time frame made it clear that secure software development had to be a dedicated practice in the organization.
Bitz said the easiest method for locating secure software development issues to foster support for change will vary from one organization to a different. He said some organizations with strong development teams is frequently capable of finding their very own flaws, but in other cases, it is necessary to rent external penetration testers to locate weaknesses that may then be leveraged in internal discussions.
Even if it takes some time to seek out flaws, Bitz said, start with the organization's flagship software, because software security problems there'll function the foremost powerful motivator for decision makers.
Attendee Bianca Lee, with the Navy Common Access Card Program Management Office (CAC PMO) on the Naval Air Station in Pensacola, Fla., agreed that searching for secure software issues internally can result in change, but that shouldn't mean ignoring external examples either.
"Your individual disaster is not the only way," Lee said, adding that there are many powerful external incidents happening regularly. "If I see my neighbor's roof is on fire, maybe I should put money into fire insurance."
View all of our RSA 2012 Conference coverage.
Nessun commento:
Posta un commento
Comments links could be nofollow free