Secure software development practices 'not rocket science' |
 |
By Colleen Frye, News Writer
03 Dec 2008 | SearchSoftwareQuality.com |
|
|
What happens when a bunch of software industry leaders put their heads together to address the ever-thorny issue of software security? They find they share a lot of common practices that can be applied across diverse environments.
|
|
|
|
|
SAFECode's guide isn't a list of best practices. This is a list of things actually being done and shown to be demonstrably secure.
Michael Howard
Microsoft's Trustworthy Computing Group
|
|
|
|
|
|
|
|
|
|
"That's the coolest part of the story," said Michael Howard, a principal security program manager in Microsoft's Trustworthy Computing Group and a contributor to the recent document "Fundamental Practices for Secure Software Development." This guide to secure development practices was released by the nonprofit Software Assurance Forum for Excellence in Code (SAFECode), which was founded last year and includes EMC, Juniper Networks, Microsoft, Nokia, SAP, and Symantec as members.
There are two striking aspects to SAFECode's guide, Howard said. "For the first time ever you see the industry agree on something from a security perspective and document it." And, he added, "This isn't a list of best practices. This is a list of things actually being done and shown to be demonstrably secure."
The guide details security practices for each stage of the software development lifecycle, which Howard said can be applied to any type of software development.
"That's one of the beauties of this document," he said. "The common ground between all the companies makes it applicable to any software out there — database applications or Web applications or embedded systems. And the way we laid it out, I think it will be relatively straightforward for developers, which is why we included links in the document."
SAFECode's recommended practices across the lifecycle are as follows:
Define a set of activities to formalize the security requirements for a specific product release.
Design: Conduct threat analysis (also called threat modeling or risk analysis) to identify architectural and design security flaws before code is committed.
Programming: Minimize unsafe function use, use the latest compiler toolset, use static and dynamic analysis tools, conduct manual code reviews, validate input and output, and more. (See the guide for additional secure programming practices.)
Testing: Recommendations include fuzz testing, penetration testing and third-party assessment, and use of automated testing tools.
Code Integrity and Handling: Implement controls to address access, storage, and handling during the development process.
Documentation: Provide details for customers on how to securely configure their software.
Of all these lifecycle practices, Howard said threat analysis is the most important, and a practice all of the guide contributors had in common.
"It was surprising to me, and I was happy to see, that all [SAFECode] vendors do some kind of threat modeling," he said. "The problem with a lot of software development from a security perspective is that a lot of it focuses on coding bugs, which is fine, but you can't lose track of design issues. The beauty of threat modeling is it helps uncover design issues and to understand which components are most at risk. It ends up being the linchpin of the rest of the process. It's critical to get it right."
For organizations looking to apply these practices, Howard said that from a technology perspective, "it's all easy. This stuff works, and it's not rocket science — you've just got to do it."
Challenges: Pushback, costs, time
One difficulty, though, could be management pushback, Howard said. "Unless the management team in your company understands that this stuff is important, it will be an uphill battle."
There are some costs to applying these practices, as well, Howard said. In terms of tooling and requirements, he said, "a lot of these things are very cheap indeed." Educating and training employees in these practices will cost some money, he said, but there are cost-effective ways to train.
Also, he said, "following these recommendations and ideas probably does add time up front. We know at Microsoft it did, then it became just part of the job, and at that point it really didn't cost more."
Howard also said many of these practices can be automated. "You can make a huge chunk of this part of your check-in requirements, so when someone checks in code there are a bunch of things that run. A big problem today with security is that there is a lot of stigma associated with it" in terms of expense. In reality, he said, organizations can get some early benefits "for minimal investment."
|
|
|
|
