WASHINGTON–Microsoft has spent several years and untold millions of dollars working on methods to write more secure and reliable software, and now the company is encouraging other organizations to make the same investment in software security.
One of the outputs of the company’s software security efforts is its much-heralded Security Development Lifecycle (SDLC), a framework for developing methods for writing secure code. However, as Microsoft has acknowledged and other experts have pointed out, the SDLC was developed specifically for Microsoft’s own internal processes and is not a one-size-fits-all methodology. But companies that are interested in using the lessons that Microsoft has learned throughout the process can use the SDLC as a starting point for their own efforts, Jim Molini, a senior program manager at Microsoft said in a talk at the OWASP AppSec DC conference here Thursday.
“If you build software, you have to focus on how you build it, because it’s becoming a higher priority attack vector right now,” he said. “They’re finding new ways to attack us and we have to find ways to buttress our software against these attacks.”
Molini said that a software security program has to be a comprehensive effort that includes everyone involved in the development process and must start with a fundamental change in the way that software is written.
“You have to eliminate the separation of security in the development organization,” he said. “It’s really going to take people working together to fix this.”
Molini also emphasized that just having a whole bunch of other developers or testers look at the code is not enough.
“Many eyeballs don’t solve the security problem. It’s more than just being able to write code,” Molini said. “It’s fixing the process aspects and the software development processes in order to reduce the number of vulnerabilities you introduce. You can’t just say zero-defect code is secure. You have to prioritize security as a development goal.”
Software security experts often say that when they show developers ways that their applications can be broken or abused, the developers protest that no user would ever do the things that broke the application. Users may not, but attackers most certainly will. To help eliminate this mentality, Molini said developers need to think like attackers and not users.
“You need to develop abuse cases, not just use cases, so that the test team can develop tests for them,” he said. “That will make your software much more secure in the long run.”
