Participation in the IEEE Center for Secure Design initiative came with a price.
“Everyone had to bring along a bag of flaws from their real SDL [software development lifecycle],” said Gary McGraw, CTO of Cigital and one of 13 authors of a new guidance document released this week for software architects called “Avoiding the Top 10 Software Security Design Flaws.”
Security and software luminaries from Twitter, Google, RSA, EMC, HP, Intel/McAfee and Cigital, along with academics from the University of Washington, George Washington University and Athens University figuratively dumped their flaws on a conference table, stacked them up and compared notes as a starting point for the top 10 list, McGraw said.
“We were surprised and delighted that we all identified many of the same flaws, so making a list of the top 10 was pretty easy,” McGraw said. “We set out about the hard work of building a document that describes how to avoid those flaws that is aimed at software architects.”
McGraw said developing guidance for architects rather than developers was a conscious effort. It also helps steer the conversation around software security away from exclusively talking about finding bugs toward design-level failures that lead to exploitable security vulnerabilities.
“One of the challenges was that because we are all from such diverse companies yet had a common ground, we had to create advice that was actionable and general enough for all to use it,” McGraw, right, said. “What we want to do in the future is begin to push the results we got now into actionable direct design advice; secure design patterns so that when companies construct their software blueprints, they’re more secure than they are now.”
The document spells out the 10 common design flaws in a straightforward manner, each with a lengthy explainer of inherent weaknesses in each area and how software designers and architects should take these potential pitfalls into consideration. The 10, in no particular order, are:
- Earn or give, but never assume, trust
- Use an authentication mechanism that cannot be bypassed or tampered with
- Authorize after you authenticate
- Strictly separate data and control instructions, and never process control instructions received from untrusted sources
- Define an approach that ensures all data are explicitly validated
- Use cryptography correctly
- Identify sensitive data and how they should be handled
- Always consider the users
- Understand how integrating external components changes your attack surface
- Be flexible when considering future changes to objects and actors
“The best use is to ponder your own designs and look for flaws in your designs; you’re guaranteed to find them,” McGraw said. “A lot of organizations are not even looking at design from a security perspective. We hope to make enough progress to spread this farther and wider.”
– Gary McGraw
Two of the companies represented in the IEEE Center for Secure Design—Google and Twitter—have already made real-world use of the advice in the doc. Twitter, represented by Neil Daswani, has already used the guidance to build an internal version for its software architects with examples from its code base, McGraw said, with advice on how to avoid using harmful frameworks and patterns. Google, represented by Christoph Kern, took some of the design ideas in the document and instituted changes in APIs available to developers in an unnamed product group at Google, and was able to eradicate cross-site scripting flaws within nine months.
McGraw said the group did not give particular weight to any of the 10 items in the guidance over another.
“I don’t think there’s that big of a delta between No. 1 and No. 10,” McGraw said. “All of them are incredibly prevalent; they’re all pretty important and it’s kind of silly to focus on one and not another.”
